I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
I, for instance, am about to disable it.
On Tue, 20 Sep 2011 08:14:18 -0300 Martín Marqués martin.marques@gmail.com wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
Yes without problems. Pretty much an essential bit of extra cover on a web server IMHO.
What sort of stuff isn't working with it ?
Alan
2011/9/20 Alan Cox alan@lxorguk.ukuu.org.uk:
On Tue, 20 Sep 2011 08:14:18 -0300 Martín Marqués martin.marques@gmail.com wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
Yes without problems. Pretty much an essential bit of extra cover on a web server IMHO.
What sort of stuff isn't working with it ?
Alan
Lots of reports with various servers:
- postfix doesn't have access to bounce directory - trac can't append to log files - abrt complains (can't remember for what).
On Tue, Sep 20, 2011 at 09:25:15 -0300, Martín Marqués martin.marques@gmail.com wrote:
Lots of reports with various servers:
- postfix doesn't have access to bounce directory
- trac can't append to log files
- abrt complains (can't remember for what).
These should be reported as bugs.
Around 12:14pm on Tuesday, September 20, 2011 (UK time), Martín Marqués scrawled:
My question is, how many people are using selinux?
Not sure how scientific this is, but I use it. Although my servers run CentOS (with SELinux). I would have thought it would be better to learn how to solve problems, and report bugs, rather than not use it.
Steve
On Tue, 2011-09-20 at 08:14 -0300, Martín Marqués wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
I, for instance, am about to disable it.
I have used it for years, hasn't really been a problem. Far less than the odd problems that have crept in with some bad program updates, that were fixed with the next update. They've been few and far between, but happen more often than I've had problems with SELinux.
Usually, the people who've had problems with it have been those that do strange things with their computer (run as root, save files all over the place, expect everything to be world-readable, et cetera). Or they want to run a server, but don't bother learning how to secure it.
I do run servers. HTTP, IMAP, POP3, SMTP, NTP, DHCP, DNS, NFS, just to list the ones I can think off, off the top of my head. None of which were a pain to get through SELinux's restrictions.
You might be better off emailing about a specific issue you've had with it.
"Martín Marqués" martin.marques@gmail.com wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
I, for instance, am about to disable it.
As with others, I've been running selinux for years on all my systems including servers. Other than the occasional need for a custom policy I've not had any problems.
On Tue, 20 Sep 2011 19:37:04 +0800 Ed Greshko wrote:
Other than the occasional need for a custom policy I've not had any problems.
And did you perform an intensive security review of the source for the program requiring the custom policy to insure that it is in fact perfectly OK to allow whatever the heck selinux was disallowing? Or (as I suspect is far more likely :-) did you just say, "OK, I need to run this program, so I'll allow that."
And, of course, the standard selinux policy files shipped with fedora have grown in the exact same fashion. The reason most folks don't have problems with selinux any longer is that all the quirks and foibles of all the programs shipped with fedora have gradually been added to the policy files, almost certainly without any of the intensive security reviews of the source which would make it marginally safe to allow those behaviors. (Because if the source had gone through that kind of review, they'd still be working on the 1st policy exception :-).
So basically, you can get a system which is every bit as secure as one running selinux by turning off selinux, and then you don't ever get bothered by the "occasional need" to write a custom policy, or get fooled into a sense of security because you have selinux turned on.
On 09/20/2011 08:07 PM, Tom Horsley wrote:
On Tue, 20 Sep 2011 19:37:04 +0800 Ed Greshko wrote:
Other than the occasional need for a custom policy I've not had any problems.
And did you perform an intensive security review of the source for the program requiring the custom policy to insure that it is in fact perfectly OK to allow whatever the heck selinux was disallowing? Or (as I suspect is far more likely :-) did you just say, "OK, I need to run this program, so I'll allow that."
I do not know what your definition of "intensive security review" is... But, yes a risk assessment were undertaken to determine why the sealert was generated and the implications of generating a policy to allow the program to run. FWIW, I didn't do all the work personally in all instances but in at least one case the code was changed as opposed to creating a custom policy.
And, of course, the standard selinux policy files shipped with fedora have grown in the exact same fashion. The reason most folks don't have problems with selinux any longer is that all the quirks and foibles of all the programs shipped with fedora have gradually been added to the policy files, almost certainly without any of the intensive security reviews of the source which would make it marginally safe to allow those behaviors. (Because if the source had gone through that kind of review, they'd still be working on the 1st policy exception :-).
I don't know if the assertion that you've made in this paragraph are true or not. I'm inclined to take what you've said as either an opinion or maybe an "educated" assumption.
So basically, you can get a system which is every bit as secure as one running selinux by turning off selinux, and then you don't ever get bothered by the "occasional need" to write a custom policy, or get fooled into a sense of security because you have selinux turned on.
It seems you are advocating to "just turn it off".?
Tom Horsley <horsley1953 <at> gmail.com> writes:
... So basically, you can get a system which is every bit as secure as one running selinux by turning off selinux, and then you don't ever get bothered by the "occasional need" to write a custom policy, or get fooled into a sense of security because you have selinux turned on.
Words of wisdom ... Same here :-) JB
On 09/20/2011 05:37 PM, Tom Horsley wrote:
And, of course, the standard selinux policy files shipped with fedora have grown in the exact same fashion. The reason most folks don't have problems with selinux any longer is that all the quirks and foibles of all the programs shipped with fedora have gradually been added to the policy files, almost certainly without any of the intensive security reviews of the source which would make it marginally safe to allow those behaviors
You are wrong. Many issues were identified and fixed in the course of writing these policies.
Rahul
2011/9/20 Ed Greshko Ed.Greshko@greshko.com:
"Martín Marqués" martin.marques@gmail.com wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
I, for instance, am about to disable it.
As with others, I've been running selinux for years on all my systems including servers. Other than the occasional need for a custom policy I've not had any problems.
OK, maybe here is the problem. I'm not used to custom policies of selinux.
For example, I moved the trac repos to /var/lib/trac, and so apache needs extra append and access policy on some of those directories. How would I add those policies?
On Tue, Sep 20, 2011 at 09:31:14 -0300, Martín Marqués martin.marques@gmail.com wrote:
For example, I moved the trac repos to /var/lib/trac, and so apache needs extra append and access policy on some of those directories. How would I add those policies?
If you move stuff around that affects the default labelling. You can use semanage and restorecon to have the new location have the correct defaults.
Giving the web server access to stuff is risky. The level of risk and benefit is something you need to evaluate. But you can label the new location so that it will be accessible to the web server. This may cause issues for other processes trying to read or write thise files. If so, you may need to do a custom policy. The simplest thing is to use audit2allow to see what access is needed to allow the service to run. (If done in enforcing mode this might take a few iterations.) However you might not want to let the web server have access to all files labelled say var_lib_t. So it may turn out that you need to create some new labels for the specific files you want to let the web server have access to.
2011/9/20 Bruno Wolff III bruno@wolff.to:
On Tue, Sep 20, 2011 at 09:31:14 -0300, Martín Marqués martin.marques@gmail.com wrote:
For example, I moved the trac repos to /var/lib/trac, and so apache needs extra append and access policy on some of those directories. How would I add those policies?
If you move stuff around that affects the default labelling. You can use semanage and restorecon to have the new location have the correct defaults.
Giving the web server access to stuff is risky. The level of risk and benefit is something you need to evaluate. But you can label the new location so that it will be accessible to the web server. This may cause issues for other processes trying to read or write thise files. If so, you may need to do a custom policy. The simplest thing is to use audit2allow to see what access is needed to allow the service to run. (If done in enforcing mode this might take a few iterations.) However you might not want to let the web server have access to all files labelled say var_lib_t. So it may turn out that you need to create some new labels for the specific files you want to let the web server have access to.
Beware of one problem with the sealert/audit2allow instructions. At least in my experience, it goes through the whole log and creates a policy to allow all denied actions, not necessarily just the one you care about. Also, the created policies can be overly generic and allow way more access than is really needed.
Richard
On Tue, Sep 20, 2011 at 09:12:37 -0500, Richard Shaw hobbes1069@gmail.com wrote:
Beware of one problem with the sealert/audit2allow instructions. At least in my experience, it goes through the whole log and creates a policy to allow all denied actions, not necessarily just the one you care about. Also, the created policies can be overly generic and allow way more access than is really needed.
I didn't state it, but yes you want to review the output and only add stuff that is believed to be appropriate.
Sitat MartÃn Marqués martin.marques@gmail.com:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
I, for instance, am about to disable it.
It depends a bit. It usually bites if you try to combine web services and other services that need to share a directory.
For my home systems, I always keep it on. I have to learn to live with it, as it definitely hardens the operating system. Why not force myself to learn it. I almost never have to touch it. Sometimes I step around selinux problems in messy ways (use a big enough hammer)
For servers on protected internal networks at work, I leave it on except on servers where it tends to create problems and other people than me need to understand what is going on. On servers where I turn it off, I often keep it in permissive mode so I can read the logs if I need to.
For servers in DMZ zones I keep it on, and I try to find clean and correct solutions to any problems instead of the sledgehammer approach at home. :-)
On Tue, 2011-09-20 at 08:14 -0300, Martín Marqués wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
Let's clarify what you've written... You are, now, trying to run a system with SELinux enabled, that was previously running with it disabled. The same files on the drive, just changing the SELinux setting. Is that right?
If so, no wonder you're having grief. While SELinux was off, your system was writing files without setting any SELinux contexts. So, those files are just default files. Now that SELinux is on, there's no contexts written in the file attributes that would tell SELinux to allow access, so the default (for safety) action is to disallow it.
On the other hand, if the system had been running with SELinux, all the time. Then all those files that were written to the drive would have had the normal SELinux contexts applied to them. So things should simply "just work," barring the occasional error (e.g. someone forgot to make a rule to set the right context; or the software programmer tried to do something less than smart, expecting full access, when they shouldn't be trying that).
Or, by re-install, do you mean that the system was installed with SELinux running normally, and you installed your user files in the same manner? Then things should simply just work. Though verbatim copying over user files with (preset) default SELinux contexts would still be a problem.
On Tuesday, September 20, 2011 10:30:38 AM Tim wrote:
On Tue, 2011-09-20 at 08:14 -0300, Martín Marqués wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
Let's clarify what you've written... You are, now, trying to run a system with SELinux enabled, that was previously running with it disabled. The same files on the drive, just changing the SELinux setting. Is that right?
If so, no wonder you're having grief. While SELinux was off, your system was writing files without setting any SELinux contexts. So, those files are just default files. Now that SELinux is on, there's no contexts written in the file attributes that would tell SELinux to allow access, so the default (for safety) action is to disallow it.
If the above is his problem, has he tried creating /.autorelabel and reboot? Please see "man selinux", "The best way to relabel the file system is to create the flag file /.autorelabel and reboot. system-config-securitylevel, also has this capability. The restorcon/fixfiles commands are also available for relabeling files."
If so, no wonder you're having grief. While SELinux was off, your system was writing files without setting any SELinux contexts. So,
If SELinux was set to permissive then it was writing data but allowing actions, if not then when you switched it on it would have done an automatic relabel on boot.
This looks like the standard SELinux and cgi stuff. It's in the RHEL/Centos manual and very well documented elsewhere.
Essentially however file permissions are not enough to enable the security policy to tell the difference between 'I've just busted your php script again' and 'legitimate access'. Labelling the cgi, scripts and data files allows you to tell it which files should be acessible and in what way - which dramatically cuts the impact of the php exploit.
Alan
2011/9/20 Alan Cox alan@lxorguk.ukuu.org.uk:
If so, no wonder you're having grief. While SELinux was off, your system was writing files without setting any SELinux contexts. So,
If SELinux was set to permissive then it was writing data but allowing actions, if not then when you switched it on it would have done an automatic relabel on boot.
Actually, that's what happened.
-- Martín Marqués select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador
Am Dienstag, den 20.09.2011, 08:14 -0300 schrieb Martín Marqués:
My question is, how many people are using selinux?
60,8% [1]
Regards, Christoph
On 09/20/2011 02:13 PM, Christoph Wickert wrote:
Am Dienstag, den 20.09.2011, 08:14 -0300 schrieb Martín Marqués:
My question is, how many people are using selinux?
60,8% [1]
Regards, Christoph
I see 68.6 % in enforcing mode ...
Am Dienstag, den 20.09.2011, 20:13 +0200 schrieb Christoph Wickert:
Am Dienstag, den 20.09.2011, 08:14 -0300 schrieb Martín Marqués:
My question is, how many people are using selinux?
60,8% [1]
Sorry, the actual percentage of people who 'use' it is 79.8% and 68.6% have it in enforcing mode.
Sorry for the typo, Christoph
Christoph Wickert wrote:
My question is, how many people are using selinux?
60,8% [1]
Sorry, the actual percentage of people who 'use' it is 79.8% and 68.6% have it in enforcing mode.
I wonder if these very high percentages are not due to the fact that the information is collected soon after CentOS is installed, when SELinux is enabled by default?
Personally, I usually run SELinux in permissive mode, due essentially to laziness, or to put a kinder word on it, because it does not come at the top of my ToDo list of priorities.
So I run it in enforcing mode until a problem comes along. If I can't solve it in say 5 minutes I move to permissive mode, with the vague intention of sorting it out sooner or later.
I'm not sure how typical I am of CentOS users; but if I am at all typical then the SELinux team should see if they cannot give a bit more "instant advice" with things to try when problems occur.
On 09/21/2011 06:09 PM, Timothy Murphy wrote:
I wonder if these very high percentages are not due to the fact that the information is collected soon after CentOS is installed, when SELinux is enabled by default?
Smolt has a cron job that keeps the profiles updated. So if you disable SELinux later, it will be reflected on the stats
Rahul
Rahul Sundaram wrote:
On 09/21/2011 06:09 PM, Timothy Murphy wrote:
I wonder if these very high percentages are not due to the fact that the information is collected soon after CentOS is installed, when SELinux is enabled by default?
Smolt has a cron job that keeps the profiles updated. So if you disable SELinux later, it will be reflected on the stats
I'm not sure why, but I see I am running /etc/cron.d/smolt on one CentOS-5.6 server, but not on a second CentOS-6.0 server. Does it depend on how one installs CentOS?
In any case, this isn't relevant to my main point, which was a request to SELinux developers to try to give simple advice with their warnings.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/21/2011 08:05 PM, Timothy Murphy wrote:
Rahul Sundaram wrote:
On 09/21/2011 06:09 PM, Timothy Murphy wrote:
I wonder if these very high percentages are not due to the fact that the information is collected soon after CentOS is installed, when SELinux is enabled by default?
Smolt has a cron job that keeps the profiles updated. So if you disable SELinux later, it will be reflected on the stats
I'm not sure why, but I see I am running /etc/cron.d/smolt on one CentOS-5.6 server, but not on a second CentOS-6.0 server. Does it depend on how one installs CentOS?
In any case, this isn't relevant to my main point, which was a request to SELinux developers to try to give simple advice with their warnings.
Have you looked at the latest setroubleshoot that is in Fedora and will be in RHEL 6.2?
http://people.redhat.com/dwalsh/SELinux/RHEL6
Daniel J Walsh wrote:
Have you looked at the latest setroubleshoot that is in Fedora and will be in RHEL 6.2?
I haven't, but I'm looking at setroubleshoot-doc, available with CentOS-6 but not with CentOS-5.6. Thanks for the suggestion.
Martín Marqués wrote:
My question is, how many people are using selinux?
I, for instance, am about to disable it.
I use it without interruption. I have not disabled it since Fedora Core 2 or 3, perhaps earlier. Since then, it has worked infallibly and without cause for gripe.
2011/9/20 Joe Zeff joe@zeff.us:
On 09/20/2011 04:14 AM, Martín Marqués wrote:
My question is, how many people are using selinux?
I, for instance, am about to disable it.
I use it on both of my computers. Why are you going to disable it? Do you like being insecure?
I spoke with someone who works in HP (system administration) that told me they have SELinux disabled on the servers, as the overhead in administration is to high.
I'd like to believe my problem is due to lack of selinux configuration knowledge, and not that it's useless.
On 20/09/2011 3:57 PM, Martín Marqués wrote:
2 I spoke with someone who works in HP (system administration) that told me they have SELinux disabled on the servers, as the overhead in administration is to high.
I'd like to believe my problem is due to lack of selinux configuration knowledge, and not that it's useless.
It`s not that it`s useless.
It`s that in the *real world*, getting the immensely-complicated policy machinery correct is next-to-impossible. And by correct, I mean ``provides security, and never causes unwanted failures of applications``.
SELinux is extremely ornate, and even after all these years, you end up running up against not-quite-right policy databases that cause you grief. Once you`ve done a few of those, the temptation is to turn it off. A properly-configured Linux server, even without SELinux, but with other security features like firewalling turned on, is likely secure-enough in many environments.
It`s that in the *real world*, getting the immensely-complicated policy machinery correct is next-to-impossible. And by correct, I mean ``provides security, and never causes unwanted failures of applications``.
For the web servers I'm running it was a simple matter of reading the manual and relabelling the relevant content to indicate if it was web accessible.
A properly-configured Linux server, even without SELinux, but with other security features like firewalling turned on, is likely secure-enough in many environments.
In some perhaps. The big cases it helps are desktop (mostly protecting against browser stuff) - where it usually just works, and web serving, where it's most definitely valuable but does mean reading the docs.
Mind you people used to say weak passwords were ok, unencrpyted sessions were ok, putting . in your path was ok, file permissions were a nuisance so login as root.
The threat model has changed and continues to evolve.
On 09/20/2011 03:10 PM, Alan Cox wrote:
In some perhaps. The big cases it helps are desktop (mostly protecting against browser stuff) - where it usually just works, and web serving, where it's most definitely valuable but does mean reading the docs.
I always find it interesting when people say that, since the browser actually runs unconfined**. There is a boolean that confines browser plugins, but its default state is OFF, and quite a few things stop working if you turn it on.
Even with all the nonstandard things I do with my system, I'm still able to run with SELinux in enforcing mode quite nicely. Prior to about Fedora 12, I couldn't do that. The tools to allow mere mortals to analyze problems and make needed policy changes weren't up to the task, and each new Fedora release made changes that forced you to throw out much of what you had learned and work it all out again. That now seems to be all in the past. My biggest problem these days is that I have so little need to use the tools that I forget how.
** I'm running CentOS 6 on my primary machine. Perhaps things are different in the latest Fedora release. # ps -Z $(pgrep firefox) LABEL PID TTY STAT TIME COMMAND unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 31756 ? Sl 2:26 /usr/lib64/firefox-3.6/firefox
On 09/20/2011 12:57 PM, Martín Marqués wrote:
I'd like to believe my problem is due to lack of selinux configuration knowledge, and not that it's useless.
Are you getting SELinux alerts? If so, it may be an issue; if not, it's a waste of time playing with it. The reason I asked is because I've seen lots of threads on fedorafourms.org where users disabled it when there were no symptoms that it was an issue then wondered why their problems didn't magically go away. I didn't want to start off by accusing you of that, but I did want to find out what symptoms there were that would point to SELinux as an issue.
As far as administrative overhead goes, I'm not a sysadmin myself, but I have some friends who are. I've read their rants about various things that give them more trouble than they're worth, but not one (that I remember) about SELinux. Maybe the admins you've been talking with haven't automated things correctly or something because for the most part, it should Just Work.
2011/9/20 Joe Zeff joe@zeff.us:
On 09/20/2011 12:57 PM, Martín Marqués wrote:
I'd like to believe my problem is due to lack of selinux configuration knowledge, and not that it's useless.
Are you getting SELinux alerts? If so, it may be an issue; if not, it's a waste of time playing with it. The reason I asked is because I've seen lots of threads on fedorafourms.org where users disabled it when there were no symptoms that it was an issue then wondered why their problems didn't magically go away. I didn't want to start off by accusing you of that, but I did want to find out what symptoms there were that would point to SELinux as an issue.
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and
basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
On 09/20/2011 16:17, Martín Marqués wrote:
2011/9/20 Joe Zeff joe@zeff.us:
On 09/20/2011 12:57 PM, Martín Marqués wrote:
I'd like to believe my problem is due to lack of selinux configuration knowledge, and not that it's useless.
Are you getting SELinux alerts? If so, it may be an issue; if not, it's a waste of time playing with it. The reason I asked is because I've seen lots of threads on fedorafourms.org where users disabled it when there were no symptoms that it was an issue then wondered why their problems didn't magically go away. I didn't want to start off by accusing you of that, but I did want to find out what symptoms there were that would point to SELinux as an issue.
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
-- Martín Marqués select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
Dave
2011/9/20 David Quigley selinux@davequigley.com:
On 09/20/2011 16:17, Martín Marqués wrote:
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
As I sad. Trac repos are at /var/lib/trac/ and append permission is needed for the trac logs.
Also saw some python execution problems from mod_python (apache).
Just now I found this:
SELinux is preventing /usr/libexec/postfix/bounce from search access on the directorio /var/spool/postfix/defer.
I've seen these before
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/20/2011 07:37 PM, Martín Marqués wrote:
2011/9/20 David Quigley selinux@davequigley.com:
On 09/20/2011 16:17, Martín Marqués wrote:
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
As I sad. Trac repos are at /var/lib/trac/ and append permission is needed for the trac logs.
Also saw some python execution problems from mod_python (apache).
Just now I found this:
SELinux is preventing /usr/libexec/postfix/bounce from search access on the directorio /var/spool/postfix/defer.
I've seen these before
The postfix bounce issue is a known problem on RHEL6. You can get a fix for this by downloading a preview of the 6.2 policy in yum repository under
http://people.redhat.com/dwalsh/SELinux/RHEL6
On 09/21/2011 09:24, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/20/2011 07:37 PM, Martín Marqués wrote:
2011/9/20 David Quigley selinux@davequigley.com:
On 09/20/2011 16:17, Martín Marqués wrote:
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
As I sad. Trac repos are at /var/lib/trac/ and append permission is needed for the trac logs.
Also saw some python execution problems from mod_python (apache).
Just now I found this:
SELinux is preventing /usr/libexec/postfix/bounce from search access on the directorio /var/spool/postfix/defer.
I've seen these before
The postfix bounce issue is a known problem on RHEL6. You can get a fix for this by downloading a preview of the 6.2 policy in yum repository under
http://people.redhat.com/dwalsh/SELinux/RHEL6
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk555YMACgkQrlYvE4MpobO2aQCfTqid8fkxu6wz5ls7xege1Fc9 +nMAnAzH6pnKJTTEBY79Xyi+dABYwg4g =zxgL -----END PGP SIGNATURE-----
[Resending since I think my message got moderated because I sent it from the wrong address]
A quick search shows that the trac people say to label the trac directory with httpd_sys_content_t (granted this is a bit old since its about FC5). It also says to label the svn directory you're using httpd_sys_content_rw_t. To make those permenant you would use (run as root) semanage fcontext -a -t httpd_sys_content_t "/var/lib/trac(/.*)?" and for svn you would do semanage fcontext -a -t httpd_sys_content_rw_t "/var/lib/svn(/.*)?" assuming that is where your svn path is. After that run restorecon on both of those directories so get the contexts setup properly.
Do those contexts seem reasonable to you Dan? The only thing that seems weird to me is that it gives the web server RW access to the svn repos. That might be needed for trac and if it is I guess its ok but I don't know enough about trac to make an educated decision. I also wonder if labeling those directories properly will fix the python issue as well.
Dave
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/21/2011 11:37 AM, David Quigley wrote:
On 09/21/2011 09:24, Daniel J Walsh wrote: On 09/20/2011 07:37 PM, Martín Marqués wrote:
2011/9/20 David Quigley selinux@davequigley.com:
On 09/20/2011 16:17, Martín Marqués wrote:
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
As I sad. Trac repos are at /var/lib/trac/ and append permission is needed for the trac logs.
Also saw some python execution problems from mod_python (apache).
Just now I found this:
SELinux is preventing /usr/libexec/postfix/bounce from search access on the directorio /var/spool/postfix/defer.
I've seen these before
The postfix bounce issue is a known problem on RHEL6. You can get a fix for this by downloading a preview of the 6.2 policy in yum repository under
http://people.redhat.com/dwalsh/SELinux/RHEL6
[Resending since I think my message got moderated because I sent it from the wrong address]
A quick search shows that the trac people say to label the trac directory with httpd_sys_content_t (granted this is a bit old since its about FC5). It also says to label the svn directory you're using httpd_sys_content_rw_t. To make those permenant you would use (run as root) semanage fcontext -a -t httpd_sys_content_t "/var/lib/trac(/.*)?" and for svn you would do semanage fcontext -a -t httpd_sys_content_rw_t "/var/lib/svn(/.*)?" assuming that is where your svn path is. After that run restorecon on both of those directories so get the contexts setup properly.
Do those contexts seem reasonable to you Dan? The only thing that seems weird to me is that it gives the web server RW access to the svn repos. That might be needed for trac and if it is I guess its ok but I don't know enough about trac to make an educated decision. I also wonder if labeling those directories properly will fix the python issue as well.
Dave
It is fine with me. Best solution would be to have a label on the process that is running trac. But if this all runs within the httpd_t domain, not much we can do.
I don't recall seeing bug reports on these packages but I guess I can look into making the label in the selinux-policy package.
On 09/21/2011 12:02, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/21/2011 11:37 AM, David Quigley wrote:
On 09/21/2011 09:24, Daniel J Walsh wrote: On 09/20/2011 07:37 PM, Martín Marqués wrote:
2011/9/20 David Quigley selinux@davequigley.com:
On 09/20/2011 16:17, Martín Marqués wrote: > > Yes, I get selinux alerts. I stated them in an earlier > mail. > > From the alerts, the only one that gave me trouble was > mod_python, and basically trac. > > Also, apache couldn't conect to the PostgreSQL server, > but that I solved easilly. > >
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
As I sad. Trac repos are at /var/lib/trac/ and append permission is needed for the trac logs.
Also saw some python execution problems from mod_python (apache).
Just now I found this:
SELinux is preventing /usr/libexec/postfix/bounce from search access on the directorio /var/spool/postfix/defer.
I've seen these before
The postfix bounce issue is a known problem on RHEL6. You can get a fix for this by downloading a preview of the 6.2 policy in yum repository under
http://people.redhat.com/dwalsh/SELinux/RHEL6
[Resending since I think my message got moderated because I sent it from the wrong address]
A quick search shows that the trac people say to label the trac directory with httpd_sys_content_t (granted this is a bit old since its about FC5). It also says to label the svn directory you're using httpd_sys_content_rw_t. To make those permenant you would use (run as root) semanage fcontext -a -t httpd_sys_content_t "/var/lib/trac(/.*)?" and for svn you would do semanage fcontext -a -t httpd_sys_content_rw_t "/var/lib/svn(/.*)?" assuming that is where your svn path is. After that run restorecon on both of those directories so get the contexts setup properly.
Do those contexts seem reasonable to you Dan? The only thing that seems weird to me is that it gives the web server RW access to the svn repos. That might be needed for trac and if it is I guess its ok but I don't know enough about trac to make an educated decision. I also wonder if labeling those directories properly will fix the python issue as well.
Dave
It is fine with me. Best solution would be to have a label on the process that is running trac. But if this all runs within the httpd_t domain, not much we can do.
I don't recall seeing bug reports on these packages but I guess I can look into making the label in the selinux-policy package. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk56CqgACgkQrlYvE4MpobMBMQCfU1NfwM4EKSgFg3TlC8PR+KFC B1IAoLqCnWgusQqzTOiq6axPvrc6MxkN =qclN -----END PGP SIGNATURE-----
While looking around for information on trac I noticed a policy module that they have written which was based on FC4 [1]. It might be worth looking at and seeing if we can make a better policy than just running as httpd.
Dave
Would the RHEL package work OK on Fedora 15? Why not push it to rawhide?
2011/9/21 Daniel J Walsh dwalsh@redhat.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/20/2011 07:37 PM, Martín Marqués wrote:
2011/9/20 David Quigley selinux@davequigley.com:
On 09/20/2011 16:17, Martín Marqués wrote:
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
As I sad. Trac repos are at /var/lib/trac/ and append permission is needed for the trac logs.
Also saw some python execution problems from mod_python (apache).
Just now I found this:
SELinux is preventing /usr/libexec/postfix/bounce from search access on the directorio /var/spool/postfix/defer.
I've seen these before
The postfix bounce issue is a known problem on RHEL6. You can get a fix for this by downloading a preview of the 6.2 policy in yum repository under
http://people.redhat.com/dwalsh/SELinux/RHEL6
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk555YMACgkQrlYvE4MpobO2aQCfTqid8fkxu6wz5ls7xege1Fc9 +nMAnAzH6pnKJTTEBY79Xyi+dABYwg4g =zxgL
-----END PGP SIGNATURE-----
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Just checked, and I have newer policy packages installed in my Fedora 15 server then the ones for RHEL6.
El día 22 de septiembre de 2011 07:36, Martín Marqués martin.marques@gmail.com escribió:
Would the RHEL package work OK on Fedora 15? Why not push it to rawhide?
2011/9/21 Daniel J Walsh dwalsh@redhat.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/20/2011 07:37 PM, Martín Marqués wrote:
2011/9/20 David Quigley selinux@davequigley.com:
On 09/20/2011 16:17, Martín Marqués wrote:
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
As I sad. Trac repos are at /var/lib/trac/ and append permission is needed for the trac logs.
Also saw some python execution problems from mod_python (apache).
Just now I found this:
SELinux is preventing /usr/libexec/postfix/bounce from search access on the directorio /var/spool/postfix/defer.
I've seen these before
The postfix bounce issue is a known problem on RHEL6. You can get a fix for this by downloading a preview of the 6.2 policy in yum repository under
http://people.redhat.com/dwalsh/SELinux/RHEL6
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk555YMACgkQrlYvE4MpobO2aQCfTqid8fkxu6wz5ls7xege1Fc9 +nMAnAzH6pnKJTTEBY79Xyi+dABYwg4g =zxgL
-----END PGP SIGNATURE-----
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
-- Martín Marqués select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/22/2011 06:36 AM, Martín Marqués wrote:
Would the RHEL package work OK on Fedora 15? Why not push it to rawhide?
The fix is in F16/Rawhide, I am not sure if it was back ported to F15, if not it is a bug.
2011/9/21 Daniel J Walsh dwalsh@redhat.com: On 09/20/2011 07:37 PM, Martín Marqués wrote:
2011/9/20 David Quigley selinux@davequigley.com:
On 09/20/2011 16:17, Martín Marqués wrote:
Yes, I get selinux alerts. I stated them in an earlier mail.
From the alerts, the only one that gave me trouble was mod_python, and basically trac.
Also, apache couldn't conect to the PostgreSQL server, but that I solved easilly.
You mentioned earlier in the thread that you changed the location of some things. Could you mention the customizations you've done so Dan or I can help you with updating your file contexts properly? Also posting your AVC denials to the fedora SELinux list would help us figure out if its your setup or if its the policy itself that is wrong. I guess you could post them here as well if people are interested.
As I sad. Trac repos are at /var/lib/trac/ and append permission is needed for the trac logs.
Also saw some python execution problems from mod_python (apache).
Just now I found this:
SELinux is preventing /usr/libexec/postfix/bounce from search access on the directorio /var/spool/postfix/defer.
I've seen these before
The postfix bounce issue is a known problem on RHEL6. You can get a fix for this by downloading a preview of the 6.2 policy in yum repository under
http://people.redhat.com/dwalsh/SELinux/RHEL6
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
On 09/20/2011 04:14 AM, Martín Marqués wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
I, for instance, am about to disable it.
I use it. The more I use it, the more I like it.
After I took the time to watch a couple of presentations on youtube and read a couple of introductory papers, the "flask" concept of keeping related items in a container started making a lot of sense.
The comments and support on this list have been helpful too.
--- John
Martín Marqués martin.marques@gmail.com wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
SELinux is a mighty thing, but it's way too complex. It's missing proper tools to manage it, and it's also not very well documented. I used SELinux for years, but even for their own distribution, the Fedora people never managed to maintain a SELinux policy that just works with their own services.
Yes, all problems got fixed with updates of the SELinux policy packages sooner or later, but until these updates were released, for every problem I spend a lot of time to find workarounds so that I can use my computer again (thanks to Red Hat's Bugzilla and all the other Fedora users with the same problems).
SELinux on Fedora works okay if you use your computer as an end-user workstation with the minimum of local services. But on such a system, SELinux doesn't have much to do.
As soon as you enable services shipped with Fedora or even try to install your own ones, you'll get into trouble eventually.
Yes, there are tools to scan SELinux log files and create exceptions, but I ended up with hundreds of exceptions. And to be honest, I don't understand what they do exactly. I cannot trust SELinux any longer. That doesn't give me any additional security.
SELinux has wasted too much time of my life over the years, so I decided to no longer use it. I keep my computers up to date and configure them properly. If that isn't enough, bad luck.
SELinux is a nice concept, but for me it has failed because it's not really usable.
Greetings, Andreas
Hi Andreas, "SELinux has wasted too much time of my life over the years, so I decided to no longer use it. I keep my computers up to date and configure them properly. If that isn't enough, bad luck."
You shoudn't have any problems at all... c'on, it's GNU/Linux! Even a local firewall is obsolete depending on what will be your system used for :D And as you say SELinux is intrinsically complicated and bloated. If you ever need such type of protection try Tomoyo, something between SELinux and Apparmor but better and actively developed.
On Sat, 2011-09-24 at 21:19 -0300, Martin Cigorraga wrote:
Hi Andreas, "SELinux has wasted too much time of my life over the years, so I decided to no longer use it. I keep my computers up to date and configure them properly. If that isn't enough, bad luck."
You shoudn't have any problems at all... c'on, it's GNU/Linux! Even a local firewall is obsolete depending on what will be your system used for :D And as you say SELinux is intrinsically complicated and bloated. If you ever need such type of protection try Tomoyo, something between SELinux and Apparmor but better and actively developed.
---- don't know about tomoyo. Have some experience with apparmor on Ubuntu (seems weak / barely implemented / easily defeated) and of course SELinux.
It seems that the team working on SELinux has substantially grown, the tools have matured, the processes more deeply identified and the support greatly enhanced and thus by any definition... actively developed.
Your choice not to use it is of course your own but I can assure you that it is indeed possible to use it, create a reasonably effective security layer through it with a minimum level of difficulty - or at least a manageable level of difficulty if you are pre-disposed to creating files in one location and moving them to an entirely different location which is certain to create contextual problems.
Craig
On 09/24/2011 09:43 PM, Craig White wrote:
if you are pre-disposed tocreating files in one location and moving them to an entirely different location which is certain to create contextual problems.
If there is a reasonably small set of locations into which you are habitually moving files, you can always configure the 'restorecond' daemon to monitor those locations and set the proper contexts.
On Sat, 2011-09-24 at 19:43 -0700, Craig White wrote:
Your choice not to use it is of course your own but I can assure you that it is indeed possible to use it, create a reasonably effective security layer through it with a minimum level of difficulty - or at least a manageable level of difficulty if you are pre-disposed to creating files in one location and moving them to an entirely different location which is certain to create contextual problems.
By and large, I wouldn't put learning to deal with SELinux, properly, about on a par with learning to firewall a network properly. And similarly painful for people to deal with when they have strange/dopey work habits.
I wish the context names weren't so darn weird though. Long to type, and unintuitive.
e.g. "unconfined_u:object_r:user_home_t" I'd *have* to read a manual to know what "u," "r," and "t" refer to. You can't tell just by reading them.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/20/2011 06:14 AM, Martín Marqués wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
I, for instance, am about to disable it.
Have a look at "SELinux for Mere Mortals" at:
http://www.redhat.com/summit/2011/presentations/
I hope it helps.
Thomas
On 10/02/2011 10:48 AM, Thomas Cameron wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/20/2011 06:14 AM, Martín Marqués wrote:
I reinstalled (better hardware) a server and had selinux enabled (was disabled before), and I starting to see why so many people don't use selinux.
My question is, how many people are using selinux?
I, for instance, am about to disable it.
Have a look at "SELinux for Mere Mortals" at:
http://www.redhat.com/summit/2011/presentations/
I hope it helps.
Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/
iEYEARECAAYFAk6IeaAACgkQmzle50YHwaB1ZgCguxjtvyQeGv2UTz3GuddPjAV4 jzMAn0lLKEV+u0J8jg4y3Uro4VDHuLoa =sXjk -----END PGP SIGNATURE-----
In F15 they have made it very easy to fix Selinux warnings. when a selinux warning Icon appears on panel bar, open it and in window click on Troubleshoot, and in there it gives a command to run from command line to fix the SeLinux errors.
Everytime I install the driver I had to download from Samsung for my Laser Printer it produces six different Selinux error messages, I just click on Troubleshoot in SeLinux window and run those commands from the command line as SU and I never see those SeLinux errors any more.
On 10/02/2011 09:08 AM, mickey wrote:
In F15 they have made it very easy to fix Selinux warnings. when a selinux warning Icon appears on panel bar, open it and in window click on Troubleshoot, and in there it gives a command to run from command line to fix the SeLinux errors.
Also in F14.
-
Alan Cox -
Andreas M. Kirchwitz -
Birger Monsen -
Bruno Wolff III -
Christoph Wickert -
Craig White -
Daniel J Walsh -
David Quigley -
Ed Greshko -
Genes MailLists -
JB -
Joe Zeff -
Marcus Leech -
Martín Cigorraga -
Martín Marqués -
Mickey -
Peter G. -
Rahul Sundaram -
Richard Sewill -
Richard Shaw -
Robert Nichols -
Skunk Worx -
Steve Searle -
thomas cameron -
Tim -
Timothy Murphy -
Tom Horsley