Since someone asked, here's my little SELinux rant:
Yesterday I set up a new server running F8. It's replacing an old server and all it does is run sshd and openvpn. I decided to give SELinux a try after many years of ignoring it.
I copied user home directories, /etc/passwd, /etc/shadow, /etc/group, and ssh host keys from the old server to the new one. That was easy enough.
I couldn't log into the machine using ssh public key authentication, though--ssh kept falling back to password authentication. I checked all the usual suspects like directory permissions, to no avail. I passed -v -v -v to ssh and got no useful information.
After some poking around I noticed a bunch of messages in /var/log/messages along the lines of "audit denied sshd btmp" and "audit denied sshd /home/eswierk/..." blah blah blah. I figured this was due to SELinux (although heaven knows why the message doesn't contain the word "selinux"). Spent some time searching Google and came across fixfiles, so I ran "fixfiles restore /", restarted sshd, and voila, I could log in with a public key.
Next I copied the openvpn configuration from the old server and tried to start it up. No joy. Having learned my lesson I headed straight to /var/log/messages and once again found messages from SELinux, like "audit denied openvpn ipp.txt". I ran "fixfiles restore /" again, but this time it didn't help. Back to Google, and dug up some mailing list messages with all sorts of stuff about updating policies. I spent about 10 minutes trying various things without really understanding them before resorting to the solution I do understand: set SELINUX=disabled in /etc/sysconfig/selinux, reboot, done.
For me learning SELinux seems as pointless as trying to remember iptables commands, or AFS trivia back when I was a student--all cause me trouble just infrequently enough to ensure I have to relearn them from scratch every time. If I were a full-time sysadmin of course it would be a different story, but I really don't have the brain cycles to remember anything more complicated than chmod and chown, and I suspect a large number of accidental sysadmins feel the same.
--Ed
Could you explain how you 'copied' these configuration files? Is this tar/untar ? I'm trying to figure out how the labels for stuff in ~/.ssh got messed up for you.
as to ipp.txt i don't know what it is so I can't even begin to guess....
-Eric
On Thu, 2008-01-03 at 13:29 -0800, Ed Swierk wrote:
Since someone asked, here's my little SELinux rant:
Yesterday I set up a new server running F8. It's replacing an old server and all it does is run sshd and openvpn. I decided to give SELinux a try after many years of ignoring it.
I copied user home directories, /etc/passwd, /etc/shadow, /etc/group, and ssh host keys from the old server to the new one. That was easy enough.
I couldn't log into the machine using ssh public key authentication, though--ssh kept falling back to password authentication. I checked all the usual suspects like directory permissions, to no avail. I passed -v -v -v to ssh and got no useful information.
After some poking around I noticed a bunch of messages in /var/log/messages along the lines of "audit denied sshd btmp" and "audit denied sshd /home/eswierk/..." blah blah blah. I figured this was due to SELinux (although heaven knows why the message doesn't contain the word "selinux"). Spent some time searching Google and came across fixfiles, so I ran "fixfiles restore /", restarted sshd, and voila, I could log in with a public key.
Next I copied the openvpn configuration from the old server and tried to start it up. No joy. Having learned my lesson I headed straight to /var/log/messages and once again found messages from SELinux, like "audit denied openvpn ipp.txt". I ran "fixfiles restore /" again, but this time it didn't help. Back to Google, and dug up some mailing list messages with all sorts of stuff about updating policies. I spent about 10 minutes trying various things without really understanding them before resorting to the solution I do understand: set SELINUX=disabled in /etc/sysconfig/selinux, reboot, done.
For me learning SELinux seems as pointless as trying to remember iptables commands, or AFS trivia back when I was a student--all cause me trouble just infrequently enough to ensure I have to relearn them from scratch every time. If I were a full-time sysadmin of course it would be a different story, but I really don't have the brain cycles to remember anything more complicated than chmod and chown, and I suspect a large number of accidental sysadmins feel the same.
--Ed
On 1/3/08, Eric Paris eparis@redhat.com wrote:
Could you explain how you 'copied' these configuration files? Is this tar/untar ? I'm trying to figure out how the labels for stuff in ~/.ssh got messed up for you.
Yes, I used tar to copy /home and /etc/openvpn. Openvpn stores state for active connections in a file specified by the --ifconfig-pool-persist option. Since the openvpn configuration recipe I found online uses /etc/openvpn/ipp.txt, that's what I use. Presumably the SELinux policy wants me to store that file somewhere else?
--Ed
Dnia 03-01-2008, czw o godzinie 13:49 -0800, Ed Swierk pisze:
On 1/3/08, Eric Paris eparis@redhat.com wrote:
Could you explain how you 'copied' these configuration files? Is this tar/untar ? I'm trying to figure out how the labels for stuff in ~/.ssh got messed up for you.
tar with "--xattrs"?
Yes, I used tar to copy /home and /etc/openvpn. Openvpn stores state for active connections in a file specified by the --ifconfig-pool-persist option. Since the openvpn configuration recipe I found online uses /etc/openvpn/ipp.txt, that's what I use. Presumably the SELinux policy wants me to store that file somewhere else?
SELinux don't care about file location. It cares about labels. Policy for *labeling* files and assorted utilities care for paths, but they are only additional utilities, not SELinux itself.. In your situation, ipp.txt must be writable by openvpn daemon. You can achieve it by labeling (man chcon) ipp.txt as openvpn_var_log_t. By default files in /etc/openvpn are labeled as openvpn_etc_t (openvpn's configuration files). Daemons cannot modify their configuration files.
On 1/4/08, Tomasz Torcz tomek@crocom.com.pl wrote:
tar with "--xattrs"?
No, I didn't realize --xattrs existed; the tar info page doesn't mention it. Oh, there it is in the man page.
Is there some reason why storing extended attributes by default would be undesirable? I normally expect tar to carry all relevant metadata with it; that's sort of the point of using tar.
SELinux don't care about file location. It cares about labels. Policy for *labeling* files and assorted utilities care for paths, but they are only additional utilities, not SELinux itself.. In your situation, ipp.txt must be writable by openvpn daemon. You can achieve it by labeling (man chcon) ipp.txt as openvpn_var_log_t. By default files in /etc/openvpn are labeled as openvpn_etc_t (openvpn's configuration files). Daemons cannot modify their configuration files.
I see. I now notice ls has a -Z option that shows the SELinux security context.
It would be nice if ls -l would show the security context by default when SELinux is enabled, as the context is apparently just as important as file permissions.
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux (despite the fact that it makes the output too wide for an 80-column display).
--Ed
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
On 1/4/08, John Dennis jdennis@redhat.com wrote:
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
The machine in question is a server with no graphical applications; is there a command-line version of setroubleshoot?
--Ed
On Jan 4, 2008 11:26 AM, Ed Swierk eswierk@arastra.com wrote:
On 1/4/08, John Dennis jdennis@redhat.com wrote:
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
The machine in question is a server with no graphical applications; is there a command-line version of setroubleshoot?
One would hope you would have installed it by now. There is a very nice command-line usage of setroubleshoot. I have never used the UI myself. Frankly, I don't know how you've been using SELinux without setroubleshoot.
On 1/4/08, Arthur Pemberton pemboa@gmail.com wrote:
One would hope you would have installed it by now. There is a very nice command-line usage of setroubleshoot. I have never used the UI myself. Frankly, I don't know how you've been using SELinux without setroubleshoot.
It wasn't installed by default and I don't know how I should have known to look for it (again, the audit log messages don't even mention SELinux). If this is considered a key part of SELinux then Anaconda shouldn't enable SELinux without it.
I assumed it was graphics-only because yum wants to drag in all sorts of gnome and gtk2-related packages when I install it.
--Ed
On Jan 4, 2008 12:01 PM, Ed Swierk eswierk@arastra.com wrote:
On 1/4/08, Arthur Pemberton pemboa@gmail.com wrote:
One would hope you would have installed it by now. There is a very nice command-line usage of setroubleshoot. I have never used the UI myself. Frankly, I don't know how you've been using SELinux without setroubleshoot.
It wasn't installed by default and I don't know how I should have known to look for it (again, the audit log messages don't even mention SELinux). If this is considered a key part of SELinux then Anaconda shouldn't enable SELinux without it.
Well it's a key component to managing SELinux, it doesn't actually help SELinux to work.
I assumed it was graphics-only because yum wants to drag in all sorts of gnome and gtk2-related packages when I install it.
Yah. I'm not fond of how it is packaged myself... but since I can't do better, i don't complain about it... it really does drag in too much stuff however.
On Jan 4, 2008 12:03 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Arthur Pemberton wrote:
Yah. I'm not fond of how it is packaged myself... but since I can't do better, i don't complain about it... it really does drag in too much stuff however.
Complaining in bugzilla would be a useful contribution.
Not a big enough deal. I'm not pulling my weight enough to be nitpicking about a few more files.
Arthur Pemberton wrote:
Yah. I'm not fond of how it is packaged myself... but since I can't do better, i don't complain about it... it really does drag in too much stuff however.
That's why setroubleshoot-server is a separate package, so it doesn't drag in all the other cruft the GUI needs.
On Jan 4, 2008 12:17 PM, John Dennis jdennis@redhat.com wrote:
Arthur Pemberton wrote:
Yah. I'm not fond of how it is packaged myself... but since I can't do better, i don't complain about it... it really does drag in too much stuff however.
That's why setroubleshoot-server is a separate package, so it doesn't drag in all the other cruft the GUI needs.
That's the point I was trying to make.
Ed Swierk wrote:
On 1/4/08, John Dennis jdennis@redhat.com wrote:
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
The machine in question is a server with no graphical applications; is there a command-line version of setroubleshoot?
Yes, setroubleshoot-server.
You have two options for receiving the alerts from the headless server. You can either run the gui on a machine with a head and point it at the headless server (requires modifying the config file to use TCP rather than the default Unix domain sockets).
On the headless server edit /etc/setroubleshoot/setroubleshoot.cfg and in the listen_for_client section set the address_list parameter to {inet}server.ip.addr. Then on the GUI system do the same thing except set the address_list in the client_connect_to section.
-OR-
You can choose to have the headless server send you emails with the alert by editing the file
/var/lib/setroubleshoot/email_alert_recipients
and adding a line like this:
user@example.com filter_type=after_first
The filter_type specifies whether to filter the email alert, the 3 possible values are:
after_first filter the email after the first notification always always filter, thus never send an email alert never never filter, thus always send an email alert
John Dennis wrote:
You have two options for receiving the alerts from the headless server.
Oh, forgot to mention, those will get you realtime alert sent to you. But you can use sealert in command line mode too.
The alert will be logged to syslog with an ID, then you can:
% sealert -l ID
-or-
You can scan the audit log file (or any other log file) with:
% sealert -a logfile
On 1/4/08, John Dennis jdennis@redhat.com wrote:
You have two options for receiving the alerts from the headless server. You can either run the gui on a machine with a head and point it at the headless server (requires modifying the config file to use TCP rather than the default Unix domain sockets).
[truncated]
I appreciate your taking the time to explain setroubleshoot but anything that involves configuring daemons and email addresses is a usability hurdle in itself.
If the mysterious audit log messages can't be made clearer, then can't we have a simple command-line tool to translate a message into a friendlier form?
--Ed
On Jan 4, 2008 2:44 PM, Ed Swierk eswierk@arastra.com wrote:
If the mysterious audit log messages can't be made clearer, then can't we have a simple command-line tool to translate a message into a friendlier form?
Generally, audit2why and audit2allow are your best friends when making first inroads with SELinux.
Regards,
Ed Swierk wrote:
If the mysterious audit log messages can't be made clearer, then can't we have a simple command-line tool to translate a message into a friendlier form?
% sudo sealert -a /var/log/audit/audit.log
On Jan 4, 2008 1:44 PM, Ed Swierk eswierk@arastra.com wrote:
On 1/4/08, John Dennis jdennis@redhat.com wrote:
You have two options for receiving the alerts from the headless server. You can either run the gui on a machine with a head and point it at the headless server (requires modifying the config file to use TCP rather than the default Unix domain sockets).
[truncated]
I appreciate your taking the time to explain setroubleshoot but anything that involves configuring daemons and email addresses is a usability hurdle in itself.
If the mysterious audit log messages can't be made clearer, then can't we have a simple command-line tool to translate a message into a friendlier form?
--Ed
Please try setroubleshot.
Ed Swierk wrote:
On 1/4/08, John Dennis jdennis@redhat.com wrote:
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
The machine in question is a server with no graphical applications; is there a command-line version of setroubleshoot?
As long as you have the X client libs installed you should be able to run GUI programs with remote display if you 'ssh -Y' to the machine from a terminal window on your desktop.
On 2008-01-04, 17:07 GMT, John Dennis wrote:
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
But you should probably emphasize more that relabel needs to be done on systems where SELinux was not used before. I know it is in man page, but apparently there are still very smart people who didn't get the memo.
Matěj
On 04/01/2008, John Dennis jdennis@redhat.com wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
The problem is, the notifications don't tell you much more than the obscure avc denial in most cases. But there's a bigger problem than that. Here's what happens when most people have an avc denial:
1) setroubleshoot pops up detailing the denial. The only really intelligible part of the information there to the non expert is "please file a report in bugzilla".
2) User thinks "oh, must be yet another problem with the selinux policy" and files a bug.
3) Dan or his team fix the problem with the policy extremely rapidly. New policy packages are installed.
4) Goto 1.
The problem is: setroubleshoot teaches average users that avc denials come about due to bugs in selinux policy. If there was some massive security problem right now on my machine causing avc denials I'd probably react by filing a stack of bug reports. This is the fundamental problem as it stands with SElinux. If it was working, we would be in a situation where the first responce to an avc denial is "OMG there's a security issue with something running on my machine, I must fix that".
On Jan 4, 2008 4:30 PM, Jonathan Underwood jonathan.underwood@gmail.com wrote:
On 04/01/2008, John Dennis jdennis@redhat.com wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
The problem is, the notifications don't tell you much more than the obscure avc denial in most cases. But there's a bigger problem than that. Here's what happens when most people have an avc denial:
- setroubleshoot pops up detailing the denial. The only really
intelligible part of the information there to the non expert is "please file a report in bugzilla".
I don't know how the GUI version works, maybe you should try the console version.
- User thinks "oh, must be yet another problem with the selinux
policy" and files a bug.
Why wouldn't they think "oh the program I am using and which is being denied by SELInux might have a bug" ?
- Dan or his team fix the problem with the policy extremely rapidly.
New policy packages are installed.
Are you referring to a specific policy?
- Goto 1.
The problem is: setroubleshoot teaches average users that avc denials come about due to bugs in selinux policy.
I get the feeling you're refering to some specific incident(s) as I have never had a avn denial due to a SELinux bug (as far as I can remember)
If there was some massive security problem right now on my machine causing avc denials I'd probably react by filing a stack of bug reports. This is the fundamental problem as it stands with SElinux.
No offence, but you _really_ should check the message before you file a bug as is often makes sense. Or has SELinux taken a nose dive in F8 that I don't know about?
If it was working, we would be in a situation where the first responce to an avc denial is "OMG there's a security issue with something running on my machine, I must fix that".
Again, I'm maybe missing information...but that's my first response when I see an SELinux denial, esp. after it saved me from being rooted once.
On 04/01/2008, Arthur Pemberton pemboa@gmail.com wrote:
- User thinks "oh, must be yet another problem with the selinux
policy" and files a bug.
Why wouldn't they think "oh the program I am using and which is being denied by SELInux might have a bug" ?
Because most of the time it's an selinux policy bug. Granted, not always, but often enough to make ones first thought be "oh, must be an selinux problem, Ill turn it off" or "must be an selinux polciy problem I'll run audit2allow and report a bug" - both of which are suggested EVERY TIME by setroubleshoot. A naive user is then led to think that this is the right thing to do in all instances.
- Dan or his team fix the problem with the policy extremely rapidly.
New policy packages are installed.
Are you referring to a specific policy?
Yep, the Fedora ones of the last few releases :)
- Goto 1.
The problem is: setroubleshoot teaches average users that avc denials come about due to bugs in selinux policy.
I get the feeling you're refering to some specific incident(s) as I have never had a avn denial due to a SELinux bug (as far as I can remember)
If there was some massive security problem right now on my machine causing avc denials I'd probably react by filing a stack of bug reports. This is the fundamental problem as it stands with SElinux.
No offence, but you _really_ should check the message before you file a bug as is often makes sense.
Of course, I know that. Many users may not, however.
Or has SELinux taken a nose dive in F8 that I don't know about?
No, things are improving all the time.:)
If it was working, we would be in a situation where the first responce to an avc denial is "OMG there's a security issue with something running on my machine, I must fix that".
Again, I'm maybe missing information...but that's my first response when I see an SELinux denial, esp. after it saved me from being rooted once.
I fear you're in the minority of users. Look over at the users forum/lists and see how many times you see people turning off selinux...
J.
On Jan 4, 2008 4:57 PM, Jonathan Underwood jonathan.underwood@gmail.com wrote:
Because most of the time it's an selinux policy bug. Granted, not always, but often enough to make ones first thought be "oh, must be an selinux problem, Ill turn it off" or "must be an selinux polciy problem I'll run audit2allow and report a bug" - both of which are suggested EVERY TIME by setroubleshoot. A naive user is then led to think that this is the right thing to do in all instances.
I have to say, it appears that my experiences with SELinux have been much different from yours. I must admit however, that I do not run SELinux on my desktops, maybe that's the issue -- I don't connect my desktop directly to the internet either however, nor do I store that much data on them.
<snip>
I fear you're in the minority of users. Look over at the users forum/lists and see how many times you see people turning off selinux...
Have you considered the possibility of a large silent majority for whom it works most of the time and so need not complain? Not that valid complaints are a bad thing.
On 1/4/08, Arthur Pemberton pemboa@gmail.com wrote:
Have you considered the possibility of a large silent majority for whom it works most of the time and so need not complain? Not that valid complaints are a bad thing.
Without actual data it's impossible to know what the silent majority is doing (although I have my suspicions). Is this a statistic that the automatic hardware profiling whatchamacallit can help collect?
--Ed
On Jan 4, 2008 5:24 PM, Ed Swierk eswierk@arastra.com wrote:
On 1/4/08, Arthur Pemberton pemboa@gmail.com wrote:
Have you considered the possibility of a large silent majority for whom it works most of the time and so need not complain? Not that valid complaints are a bad thing.
Without actual data it's impossible to know what the silent majority is doing (although I have my suspicions). Is this a statistic that the automatic hardware profiling whatchamacallit can help collect?
I don't know, just attempting to provide an alternate view point.
On 04/01/2008, Arthur Pemberton pemboa@gmail.com wrote:
Have you considered the possibility of a large silent majority for whom it works most of the time and so need not complain? Not that valid complaints are a bad thing.
That could be the case. Perhaps there's something that could be added to Smolt to allow the history of avc denials to be uploaded as part of the profile - that would allow some really interesting analysis.
My main point really is about the advice that setroubleshoot gives, as detailed previously.
J.
On Jan 4, 2008 6:54 PM, Jonathan Underwood jonathan.underwood@gmail.com wrote:
That could be the case. Perhaps there's something that could be added to Smolt to allow the history of avc denials to be uploaded as part of the profile - that would allow some really interesting analysis.
That is a great idea!
Even just something that indicates the proportion of people using enforcing/permissive/disabled. That would be useful to either support or refute the periodic SELinux rant threads based on people's personal usage patterns and seem to take on a life of their own and inevitably lead to statistics being pulled out of thin air.
/Mike
Michael Wiktowy wrote:
On Jan 4, 2008 6:54 PM, Jonathan Underwood jonathan.underwood@gmail.com wrote:
That could be the case. Perhaps there's something that could be added to Smolt to allow the history of avc denials to be uploaded as part of the profile - that would allow some really interesting analysis.
That is a great idea!
Even just something that indicates the proportion of people using enforcing/permissive/disabled. That would be useful to either support or refute the periodic SELinux rant threads based on people's personal usage patterns and seem to take on a life of their own and inevitably lead to statistics being pulled out of thin air.
For what it's worth setroubleshoot was designed to allow sending it's analysis to a central server to coalesce all the reports to get a global view (and to allow notifications to be sent back to the reporter when their issue was fixed if it was a bug). This was never fully implemented for the following reasons:
* audit data is security sensitive, transmitting it to a central server raises a host of issues.
* we needed a host to run the server on, at the time none existed (fedoraproject might be a viable option today).
* no one thought it was important.
The code in setroubleshoot still has all the logic built into it to support central aggregation, as it has from day one. But we would have to build the central server and solve the security issues. But this would occur if and only if there was a consensus this was important and volunteers stepped forward to perform the work.
On Fri, 4 Jan 2008, Jonathan Underwood wrote:
On 04/01/2008, Arthur Pemberton pemboa@gmail.com wrote:
Have you considered the possibility of a large silent majority for whom it works most of the time and so need not complain? Not that valid complaints are a bad thing.
That could be the case. Perhaps there's something that could be added to Smolt to allow the history of avc denials to be uploaded as part of the profile - that would allow some really interesting analysis.
Smolt has been collecting this information, but it has not yet been published on the web site (hopefully soon).
- James
On Jan 6, 2008 5:51 PM, James Morris jmorris@namei.org wrote:
That could be the case. Perhaps there's something that could be added to Smolt to allow the history of avc denials to be uploaded as part of the profile - that would allow some really interesting analysis.
Smolt has been collecting this information, but it has not yet been published on the web site (hopefully soon).
Smolt doesn't collect that information, and that seems like a bad idea for something for Smolt to collect. Well, if you wanted to make something like kerneloops, but called selinuxoops, then maybe we can link Smolt information together on an opt-in basis. I'm not sure what you would gain by knowing what kind of CPU generated an SELinux error, it would be no different than diagnosing permissions problems remotely. It's all in the software.
-Yaakov
On Sun, 2008-01-06 at 18:05 -0500, Yaakov Nemoy wrote:
On Jan 6, 2008 5:51 PM, James Morris jmorris@namei.org wrote:
That could be the case. Perhaps there's something that could be added to Smolt to allow the history of avc denials to be uploaded as part of the profile - that would allow some really interesting analysis.
Smolt has been collecting this information, but it has not yet been published on the web site (hopefully soon).
Smolt doesn't collect that information, and that seems like a bad idea for something for Smolt to collect. Well, if you wanted to make something like kerneloops, but called selinuxoops, then maybe we can link Smolt information together on an opt-in basis. I'm not sure what you would gain by knowing what kind of CPU generated an SELinux error, it would be no different than diagnosing permissions problems remotely. It's all in the software.
I don't know all the details but I do know smolt is collecting the number of users who are leaving selinux turned on vs off. I haven't heard anything about AVC denial counts and stuff like that. Hopefully we will soon have published numbers about how many people are 'happily' running with selinux.
-Eric
James Morris wrote:
On Fri, 4 Jan 2008, Jonathan Underwood wrote:
On 04/01/2008, Arthur Pemberton pemboa@gmail.com wrote:
Have you considered the possibility of a large silent majority for whom it works most of the time and so need not complain? Not that valid complaints are a bad thing.
That could be the case. Perhaps there's something that could be added to Smolt to allow the history of avc denials to be uploaded as part of the profile - that would allow some really interesting analysis.
Smolt has been collecting this information, but it has not yet been published on the web site (hopefully soon).
I'd expect these numbers to be overwhelmed by groups that (a) don't run any services that need special handling and (b) run 3rd party apps that aren't integrated in the policy and disable selinux so they work at all. Do you have a way to distinguish these from people running something with a fixable policy issue or account for them if you try to draw conclusions from the reported values?
Jonathan Underwood wrote:
The problem is: setroubleshoot teaches average users that avc denials come about due to bugs in selinux policy. If there was some massive security problem right now on my machine causing avc denials I'd probably react by filing a stack of bug reports. This is the fundamental problem as it stands with SElinux. If it was working, we would be in a situation where the first responce to an avc denial is "OMG there's a security issue with something running on my machine, I must fix that".
True enough, but that (trusting denials are legitimate breaches) is a goal that is not necessarily here yet... while there are still bugs being filed in policy you (or 'average users' such as me and most rawhide testers) have very little chance of knowing which is which.
That doesn't mean it is not working... a security problem thats generating denials is only a problem per se when you go and disable selinux thinking 'its just a bug I can ignore these and let it happen'.
As long as a bug is filed, and your machine is still enforcing, and someone hasn't found a way around the denials, either the policy will change or Dan is going to post back to that bug report that what is happening is definitely not going to be allowed by policy. Thats when you go fishing for your security issue.
Most people probably just go and disable it, assuming denials were from something they were trying to do and a bug prevented them from doing it. I think its very important that rawhide testers be using selinux though because there is no way to prevent policy bugs from getting to release (and the broad userbase from then disabling selinux...) otherwise.
On 04/01/2008, Andrew Farris lordmorgul@gmail.com wrote:
Jonathan Underwood wrote:
The problem is: setroubleshoot teaches average users that avc denials come about due to bugs in selinux policy. If there was some massive security problem right now on my machine causing avc denials I'd probably react by filing a stack of bug reports. This is the fundamental problem as it stands with SElinux. If it was working, we would be in a situation where the first responce to an avc denial is "OMG there's a security issue with something running on my machine, I must fix that".
True enough, but that (trusting denials are legitimate breaches) is a goal that is not necessarily here yet... while there are still bugs being filed in policy you (or 'average users' such as me and most rawhide testers) have very little chance of knowing which is which.
That doesn't mean it is not working... a security problem thats generating denials is only a problem per se when you go and disable selinux thinking 'its just a bug I can ignore these and let it happen'.
As long as a bug is filed, and your machine is still enforcing, and someone hasn't found a way around the denials, either the policy will change or Dan is going to post back to that bug report that what is happening is definitely not going to be allowed by policy. Thats when you go fishing for your security issue.
Yep, exactly. And in fact that's exactly what's happening - a good example is a bug I filed against the SElinux policy which turned out to be another program leaking file descriptors.
I worry though, because setroubleshoot suggests, amongst other things, running audit2allow to allow whatever behaviour prompted the avc denial. That's obviously very dangerous if you do it without knowing what you're allowing.
Most people probably just go and disable it, assuming denials were from something they were trying to do and a bug prevented them from doing it. I think its very important that rawhide testers be using selinux though because there is no way to prevent policy bugs from getting to release (and the broad userbase from then disabling selinux...) otherwise.
Agreed, certainly.
j.
Andrew Farris wrote:
Jonathan Underwood wrote:
The problem is: setroubleshoot teaches average users that avc denials come about due to bugs in selinux policy. If there was some massive security problem right now on my machine causing avc denials I'd probably react by filing a stack of bug reports. This is the fundamental problem as it stands with SElinux. If it was working, we would be in a situation where the first responce to an avc denial is "OMG there's a security issue with something running on my machine, I must fix that".
True enough, but that (trusting denials are legitimate breaches) is a goal that is not necessarily here yet... while there are still bugs being filed in policy you (or 'average users' such as me and most rawhide testers) have very little chance of knowing which is which.
That doesn't mean it is not working... a security problem thats generating denials is only a problem per se when you go and disable selinux thinking 'its just a bug I can ignore these and let it happen'.
As long as a bug is filed, and your machine is still enforcing, and someone hasn't found a way around the denials, either the policy will change or Dan is going to post back to that bug report that what is happening is definitely not going to be allowed by policy. Thats when you go fishing for your security issue.
Or instead of you going fishing, the bug is recategorized and someone else comes in to work with you on fixing the real problem (since odds are we are packaging whatever it is that does have the issue).
Most people probably just go and disable it, assuming denials were from something they were trying to do and a bug prevented them from doing it. I think its very important that rawhide testers be using selinux though because there is no way to prevent policy bugs from getting to release (and the broad userbase from then disabling selinux...) otherwise.
I still tell new linux users to disable selinux when they install. Its just too much to explain to someone who is already in uncomfortable territory.
--CJD
On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
Well, honorable goal, but does it actually achieve this goal?
* On one machine (FC8/x86_64), for me, all setroubleshoot does is to die shortly after bootup and first-time login (I haven't tried to investigate, but as it seems to me some serelated daemon is segfaulting).
* Is it appropriate to inform arbitrary ordinary users about SELinux issues? May-be this on single user/non-networked machines, but I don't think this is the right concept for a networked environment in which "ordinary user" normally isn't the system admin.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
- Is it appropriate to inform arbitrary ordinary users about SELinux
issues?
That's a real good point, as are the others made in this thread. I think the bottom line here is that we are still working to get the selinux policies to the point where they work 99% for 99% of users. Once we're there we should switch over to operating behaviors that assume that most violations represent real security problems --- but for now I don't think we are there yet. What the current behaviors need to do is to encourage people to report results, so that we can collect more data about real vs phony violations.
regards, tom lane
On Jan 5, 2008 12:33 AM, Ralf Corsepius rc040203@freenet.de wrote:
On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
Well, honorable goal, but does it actually achieve this goal?
- On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
shortly after bootup and first-time login (I haven't tried to investigate, but as it seems to me some serelated daemon is segfaulting).
You don't possibly think that this is the regular behaviour of setroubleshoot on which you cna judge it?
- Is it appropriate to inform arbitrary ordinary users about SELinux
issues? May-be this on single user/non-networked machines, but I don't think this is the right concept for a networked environment in which "ordinary user" normally isn't the system admin.
I'm not sure i understand the criticism here.
On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
On Jan 5, 2008 12:33 AM, Ralf Corsepius rc040203@freenet.de wrote:
On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
Well, honorable goal, but does it actually achieve this goal?
- On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
shortly after bootup and first-time login (I haven't tried to investigate, but as it seems to me some serelated daemon is segfaulting).
You don't possibly think that this is the regular behaviour of setroubleshoot on which you cna judge it?
No, I am pretty certain it's an setroubleshoot and/or its infrastructure bug.
- Is it appropriate to inform arbitrary ordinary users about SELinux
issues? May-be this on single user/non-networked machines, but I don't think this is the right concept for a networked environment in which "ordinary user" normally isn't the system admin.
I'm not sure i understand the criticism here.
The question behind this: To whom are SELinux messages/is setroubleshoot of interest and who is able to react upon them?
In production systems, it's the system admin and nobody else.
For example, think about an "ordinary (SMB) office" situation. Most of such a system's users will not administrate their machines by themselves, many of these users will be computer illiterates. All setroubleshoot offers to them is "clutter" to their desktop for issues which are "none of their business".
In a "Linux-geek@home"/"personal desktop" scenario, the situation is different. IMO, this is the scenario Fedora's current setroubleshoot is appropriate for.
Ralf
Ralf Corsepius wrote:
On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
On Jan 5, 2008 12:33 AM, Ralf Corsepius rc040203@freenet.de wrote:
On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
Well, honorable goal, but does it actually achieve this goal?
- On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
shortly after bootup and first-time login (I haven't tried to investigate, but as it seems to me some serelated daemon is segfaulting).
You don't possibly think that this is the regular behaviour of setroubleshoot on which you cna judge it?
No, I am pretty certain it's an setroubleshoot and/or its infrastructure bug.
- Is it appropriate to inform arbitrary ordinary users about SELinux
issues? May-be this on single user/non-networked machines, but I don't think this is the right concept for a networked environment in which "ordinary user" normally isn't the system admin.
I'm not sure i understand the criticism here.
The question behind this: To whom are SELinux messages/is setroubleshoot of interest and who is able to react upon them?
In production systems, it's the system admin and nobody else.
For example, think about an "ordinary (SMB) office" situation. Most of such a system's users will not administrate their machines by themselves, many of these users will be computer illiterates. All setroubleshoot offers to them is "clutter" to their desktop for issues which are "none of their business".
Naturally... which is the reason those users should not have setroubleshoot available to them... the name itself should make this obvious. Its a tool made for the development phase of a technology, not for a production system in a typical office environment.
In a "Linux-geek@home"/"personal desktop" scenario, the situation is different. IMO, this is the scenario Fedora's current setroubleshoot is appropriate for.
Yes, I've personally found it very helpful in testing rawhide in this scenario.
Ralf Corsepius wrote:
On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
On Jan 5, 2008 12:33 AM, Ralf Corsepius rc040203@freenet.de wrote:
On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
Well, honorable goal, but does it actually achieve this goal?
- On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
shortly after bootup and first-time login (I haven't tried to investigate, but as it seems to me some serelated daemon is segfaulting).
You don't possibly think that this is the regular behaviour of setroubleshoot on which you cna judge it?
No, I am pretty certain it's an setroubleshoot and/or its infrastructure bug.
And have you done with this bug what I'm sure we all know we are supposed to do with bugs we find? :P
--CJD
On Sun, 2008-01-06 at 18:49 -0500, Casey Dahlin wrote:
Ralf Corsepius wrote:
On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
On Jan 5, 2008 12:33 AM, Ralf Corsepius rc040203@freenet.de wrote:
On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux
Re SELinux usability issues:
We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it.
Well, honorable goal, but does it actually achieve this goal?
- On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
shortly after bootup and first-time login (I haven't tried to investigate, but as it seems to me some serelated daemon is segfaulting).
You don't possibly think that this is the regular behaviour of setroubleshoot on which you cna judge it?
No, I am pretty certain it's an setroubleshoot and/or its infrastructure bug.
And have you done with this bug what I'm sure we all know we are supposed to do with bugs we find? :P
Done right now.
This morning's reboot gave me another opportunity to take a somewhat deeper look ;)
https://bugzilla.redhat.com/show_bug.cgi?id=427721
Ralf
Ralf Corsepius wrote:
And have you done with this bug what I'm sure we all know we are supposed to do with bugs we find? :P
Done right now.
This morning's reboot gave me another opportunity to take a somewhat deeper look ;)
Thank you Ralf, following up with a bugzilla is very much appreciated. The key to diagnosing the problem is right there in the syslog:
setroubleshoot: [program.ERROR] Can not handle AVC'S related to the dispatcher. exiting
tcontext=unconfined_u:system_r:setroubleshootd_t:s0 scontext=unconfined_u:system_r:setroubleshootd_t:s0
This means setroubleshootd saw an AVC that it generated itself. This should never happen and to prevent infinite recursion the daemon shuts down. This is most likely due to a policy bug. There were some known policy bugs early in F8 (before GOLD) related to setroubleshoot but those should have been fixed. Is your policy up to date?
On Jan 7, 2008 11:50 AM, John Dennis jdennis@redhat.com wrote:
Ralf Corsepius wrote:
And have you done with this bug what I'm sure we all know we are supposed to do with bugs we find? :P
Done right now.
This morning's reboot gave me another opportunity to take a somewhat deeper look ;)
Thank you Ralf, following up with a bugzilla is very much appreciated. The key to diagnosing the problem is right there in the syslog:
setroubleshoot: [program.ERROR] Can not handle AVC'S related to the dispatcher. exiting
tcontext=unconfined_u:system_r:setroubleshootd_t:s0 scontext=unconfined_u:system_r:setroubleshootd_t:s0
This means setroubleshootd saw an AVC that it generated itself. This should never happen and to prevent infinite recursion the daemon shuts down. This is most likely due to a policy bug. There were some known policy bugs early in F8 (before GOLD) related to setroubleshoot but those should have been fixed. Is your policy up to date?
I have been seeing the same thing very recently with a fully up to date F8 installation that has never seen Rawhide. I thought that it was related to my LiveCD creation but I had setroubleshoot applet disconnect from the selinux deamon soon after my Sunday log rotation. I will add my logs to this bug when I get a chance.
/Mike
Ralf Corsepius wrote:
- Is it appropriate to inform arbitrary ordinary users about SELinux
issues? May-be this on single user/non-networked machines, but I don't think this is the right concept for a networked environment in which "ordinary user" normally isn't the system admin.
This is why setroubleshoot was designed to operate in a distributed network mode. At the time of setroubleshoot's initial release it was felt this was a corner case, that the most likely user of the tool would be developers and technically astute users both running locally. The distributed aspects of the tool were never promoted, although they continue to reside in the code.
In fairness the networked facilities need some enhancements to make them fully viable. For instance the network traffic is not encrypted, a critical feature when transmitting security sensitive data and it needs to be fronted by a more robust authentication mechanism.
greetings,
On Mon, Jan 07, 2008 at 02:47:48PM -0500, John Dennis wrote: [..snipped..]
In fairness the networked facilities need some enhancements to make them fully viable. For instance the network traffic is not encrypted, a critical feature when transmitting security sensitive data and it needs to be fronted by a more robust authentication mechanism.
my use case would be in a private network environment (call center, noc, etc) so the messages would not necessarily need to be encrypted.. my concern would be that they get to the central server reliably.
-- John Dennis jdennis@redhat.com
regards, --jeff
On Monday 07 January 2008 15:07:24 jam@zoidtechnologies.com wrote:
In fairness the networked facilities need some enhancements to make them fully viable. For instance the network traffic is not encrypted, a critical feature when transmitting security sensitive data and it needs to be fronted by a more robust authentication mechanism.
my use case would be in a private network environment (call center, noc, etc) so the messages would not necessarily need to be encrypted.. my concern would be that they get to the central server reliably.
There are plans to create a remote logging plugin for the audit system. This will handle more traffic than just the avc's. There are a number of issues that have to be resolved in order for this to work correctly. I hope that it will be done in time for F9.
-Steve
"JD" == John Dennis jdennis@redhat.com writes:
JD> This is why setroubleshoot was designed to operate in a JD> distributed network mode. At the time of setroubleshoot's initial JD> release it was felt this was a corner case, that the most likely JD> user of the tool would be developers and technically astute users JD> both running locally. The distributed aspects of the tool were JD> never promoted, although they continue to reside in the code.
Well, I for one would be happy to run a local server so that I can keep an eye on selinux issues on the desktops here. I've been cautiously rolling selinux out on user desktops and try to run it on servers whenever I can (which is becoming much more often as I understand more about how it works) but the only way I know there are issues is if something explicitly breaks or by reading logwatch reports.
Of course, my users should never see any kind of setroubleshoot applet; they have no idea what it would mean and they don't have privileges to make changes anyway.
- J<
On Fri, 2008-01-04 at 08:40 -0800, Ed Swierk wrote:
On 1/4/08, Tomasz Torcz tomek@crocom.com.pl wrote:
tar with "--xattrs"?
No, I didn't realize --xattrs existed; the tar info page doesn't mention it. Oh, there it is in the man page.
If I do "info tar" on Fed-8 the second hit for a search on "selinux" gives the --selinux option and the --xattrs option is visible just below it (--xattrs includes --selinux).
Is there some reason why storing extended attributes by default would be undesirable? I normally expect tar to carry all relevant metadata with it; that's sort of the point of using tar.
Well we didn't want to do this until the patch for xattrs/ACLs/SELinux is upstream as it changes the default tar format and GNU tars without the patch will display a bunch of annoying warnings. Esp. given how much tar is used to distribute software, where perms/xattrs aren't really wanted.
On 1/4/08, James Antill james.antill@redhat.com wrote:
If I do "info tar" on Fed-8 the second hit for a search on "selinux" gives the --selinux option and the --xattrs option is visible just below it (--xattrs includes --selinux).
Oh, I see. I was looking in the "All tar options" section (3.4).
--Ed
On Friday 04 January 2008 12:24:24 James Antill wrote:
Is there some reason why storing extended attributes by default would be undesirable? I normally expect tar to carry all relevant metadata with it; that's sort of the point of using tar.
Well we didn't want to do this until the patch for xattrs/ACLs/SELinux is upstream as it changes the default tar format and GNU tars without the patch will display a bunch of annoying warnings.
And furthermore...if you tar a directory up on Fedora 8 and untar it on OpenBSD machine...its not going to know what to do with the extended attributes for SE Linux. Since open source software is used across many platforms, its wasteful to turn it on by default.
-Steve
On Jan 4, 2008 11:40 AM, Ed Swierk eswierk@arastra.com wrote:
On 1/4/08, Tomasz Torcz tomek@crocom.com.pl wrote:
tar with "--xattrs"?
No, I didn't realize --xattrs existed; the tar info page doesn't mention it. Oh, there it is in the man page. I see. I now notice ls has a -Z option that shows the SELinux security context.
It would be nice if ls -l would show the security context by default when SELinux is enabled, as the context is apparently just as important as file permissions.
I started to use cp -P + rm rather than mv to shuffle around config files and files between user directories and 99% of my selinux attribute issues went away. I checked the man page for mv and didn't see anything; is there an equivalent to cp's -P parameter for mv?
/Mike
On Jan 4, 2008 2:39 PM, Michael Wiktowy michael.wiktowy@gmail.com wrote:
On Jan 4, 2008 11:40 AM, Ed Swierk eswierk@arastra.com wrote:
On 1/4/08, Tomasz Torcz tomek@crocom.com.pl wrote:
tar with "--xattrs"?
No, I didn't realize --xattrs existed; the tar info page doesn't mention it. Oh, there it is in the man page. I see. I now notice ls has a -Z option that shows the SELinux security context.
It would be nice if ls -l would show the security context by default when SELinux is enabled, as the context is apparently just as important as file permissions.
I started to use cp -P + rm rather than mv to shuffle around config files and files between user directories and 99% of my selinux attribute issues went away. I checked the man page for mv and didn't see anything; is there an equivalent to cp's -P parameter for mv?
/Mike
This has suggested before in reply to past rants.
On Jan 3, 2008 4:29 PM, Ed Swierk eswierk@arastra.com wrote:
For me learning SELinux seems as pointless as trying to remember iptables commands, or AFS trivia back when I was a student--all cause me trouble just infrequently enough to ensure I have to relearn them from scratch every time. If I were a full-time sysadmin of course it would be a different story, but I really don't have the brain cycles to remember anything more complicated than chmod and chown, and I suspect a large number of accidental sysadmins feel the same.
Well, if it's any consolation, there are those of us who really quite appreciate SELinux. It's really not that intrusive in targeted mode -- I've been running my workstations in enforcing mode for the past 2 years, and it's only fairly rarely that I find something that's not working because of SELinux. In these cases, if it's something that I have to do on a one-off basis, I just do "setenforce 0" and then "setenforce 1" when I'm done (or just leave it as is until next reboot).
Yes, SELinux is very complex, but that's because what it's trying to do is also very complex. However, it's not insurmountable to learn. Take it from someone who had to write an SELinux policy -- it took me a week worth of effort to get to the point where it worked as intended, but I finally got there. Once you wrap your brain around it, it's fairly straightforward.
Regards,
On Thu, 3 Jan 2008 13:29:18 -0800 "Ed Swierk" wrote:
Since someone asked, here's my little SELinux rant:
[ ...rant truncated... :-) ]
For me learning SELinux seems as pointless as trying to remember iptables commands, or AFS trivia back when I was a student--all cause me trouble just infrequently enough to ensure I have to relearn them from scratch every time. If I were a full-time sysadmin of course it would be a different story, but I really don't have the brain cycles to remember anything more complicated than chmod and chown, and I suspect a large number of accidental sysadmins feel the same.
I run into similar problems every time I've tried to enable SELinux. I now run it in "permissive" mode on most of my machines and watch the occasional warnings appear in /var/log/messages.
But I think the situation is improving since I'm seeing fewer warnings in F8 than with F7 or FC6. And you can install the "sealert" packages:
setroubleshoot.noarch setroubleshoot-plugins.noarch setroubleshoot-server.noarch
which provide much more detailed and helpful diagnostic messages.
Ed
Ed Swierk wrote:
For me learning SELinux seems as pointless as trying to remember iptables commands, or AFS trivia back when I was a student--all cause me trouble just infrequently enough to ensure I have to relearn them from scratch every time. If I were a full-time sysadmin of course it would be a different story, but I really don't have the brain cycles to remember anything more complicated than chmod and chown, and I suspect a large number of accidental sysadmins feel the same.
Selinux is (no argument) something that takes considerable time to start figuring out... but basically you have to start by realizing nothing is going to work right if the files aren't labeled as the policy expects them to be. This is precisely the same situation you have when file permissions are wrong and nothing will work until you fix them (selinux policy is really just a more complicated permissions system for who can use files and for what purpose).
When you started out with unices the permissions system probably took time but it eventually sank in -- so will selinux unless you continue to ignore it. Just food for thought... I'm sure everyone knows it takes time, the question becomes 'is it important' and alot of people feel the answer is yes.
As the policies improve selinux will become hardly more complicated for general use as chmod itself is... proper policy + proper label = just works. Obviously both of those need to be in place and are in progress; so disable it when you must now but if you just ignore it long term its to your detriment. Set it permissive at minimum and keep the denial log messages for additional security review if/when you really need it. And finally, the ability to disable it is in the distro precisely so that you can (so why the rant? you want to be forced to enable it instead? you feel everyone should install without it enabled by default forever and ever? you feel that selinux should disable itself when you get denials that prevent you doing what you want? uhm that won't do).
On 1/3/08, Andrew Farris lordmorgul@gmail.com wrote:
As the policies improve selinux will become hardly more complicated for general use as chmod itself is... proper policy + proper label = just works. Obviously both of those need to be in place and are in progress; so disable it when you must now but if you just ignore it long term its to your detriment. Set it permissive at minimum and keep the denial log messages for additional security review if/when you really need it. And finally, the ability to disable it is in the distro precisely so that you can (so why the rant? you want to be forced to enable it instead? you feel everyone should install without it enabled by default forever and ever? you feel that selinux should disable itself when you get denials that prevent you doing what you want? uhm that won't do).
No, no and no. Dimi raised the issue of gauging the usability of SELinux, and the only point of my rant was to convey the experience that led me to disable it.
--Ed
Ed Swierk wrote:
On 1/3/08, Andrew Farris lordmorgul@gmail.com wrote:
As the policies improve selinux will become hardly more complicated for general use as chmod itself is... proper policy + proper label = just works. Obviously both of those need to be in place and are in progress; so disable it when you must now but if you just ignore it long term its to your detriment. Set it permissive at minimum and keep the denial log messages for additional security review if/when you really need it. And finally, the ability to disable it is in the distro precisely so that you can (so why the rant? you want to be forced to enable it instead? you feel everyone should install without it enabled by default forever and ever? you feel that selinux should disable itself when you get denials that prevent you doing what you want? uhm that won't do).
No, no and no. Dimi raised the issue of gauging the usability of SELinux, and the only point of my rant was to convey the experience that led me to disable it.
--Ed
Ok I understand then, however I'd just comment that as a gauge of usability I think your situation (moving configurations across platforms, from no selinux to selinux) is somewhat of a fringe case. I realize that MANY admins would be doing just that in the process of adopting selinux since rewriting configurations is a major pain, but its still something that can almost be expected to cause headache (and requires labeling). Just my 2c on usability, it still seems to work best when you start out from install with selinux enabled and avoid deliberately circumventing it.
Would you say that documentation on that specific issue (migrating configurations) needs more attention?
The big thing is any file moved has to get labeled. Your openvpn issue looks like it might be a real policy problem.
On 1/3/08, Andrew Farris lordmorgul@gmail.com wrote:
Ok I understand then, however I'd just comment that as a gauge of usability I think your situation (moving configurations across platforms, from no selinux to selinux) is somewhat of a fringe case. I realize that MANY admins would be doing just that in the process of adopting selinux since rewriting configurations is a major pain, but its still something that can almost be expected to cause headache (and requires labeling). Just my 2c on usability, it still seems to work best when you start out from install with selinux enabled and avoid deliberately circumventing it.
Believe me, as an engineer I understand how annoying it is to learn that a user has given up in frustration after 10 minutes just because they ran into trivial issue like a bug in the installer. Unfortunately the most luxuriously smooth freeway in the world will lie unused if the on-ramps are full of land mines. :-)
Would you say that documentation on that specific issue (migrating configurations) needs more attention?
I think improving error messages and warnings and default behavior (see my earlier comments on tar and ls) is more worthwhile than writing documentation, as the latter tends not to get read.
--Ed
I think improving error messages and warnings and default behavior (see my earlier comments on tar and ls) is more worthwhile than writing documentation, as the latter tends not to get read.
+1 for the error messages. Msot of us are used to things not always quite working in the world of Unix. We're used to just taking a look at /var/log/messages and getting a pretty good idea as to what the problem is.
I guess the SELinux troubleshooter goes a long way to addressing this, so maybe there's no point to making the syslog messages a bit better for human consumption.
Ray
On Thu, Jan 03, 2008 at 05:52:56PM -0800, Andrew Farris wrote:
must now but if you just ignore it long term its to your detriment. Set it
Not necessarily. file permissions are only useful if you want privilege separation. Likewise selinux is only useful if you want fine grained file access rights.
So far, I don't need the corresponding complexity, though I know tht it is at the expense of some security.
-- Pat
On 2008-01-03, 21:29 GMT, Ed Swierk wrote:
For me learning SELinux seems as pointless as trying to remember iptables commands, or AFS trivia back when I was a student--all cause me trouble just infrequently enough to ensure I have to relearn them from scratch every time. If I were a full-time sysadmin of course it would be a different story, but I really don't have the brain cycles to remember anything more complicated than chmod and chown, and I suspect a large number of accidental sysadmins feel the same.
When introducing SELinux on computer where it wasn't before, it is mandatory to
touch /.autorelabel reboot
Matěj
On 1/4/08, Matej Cepl mcepl@redhat.com wrote:
When introducing SELinux on computer where it wasn't before, it is mandatory to
touch /.autorelabel reboot
...and when copying files from another machine not running SELinux, and when copying files from a machine running SELinux without using funny tar/cp options.
--Ed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ed Swierk wrote:
On 1/4/08, Matej Cepl mcepl@redhat.com wrote:
When introducing SELinux on computer where it wasn't before, it is mandatory to
touch /.autorelabel reboot
...and when copying files from another machine not running SELinux, and when copying files from a machine running SELinux without using funny tar/cp options.
--Ed
restorecon on the files is a better solution.
restorecon -R -v /etc
for example.