Re: [CentOS] Odd failure of smbd to start from init.d - CentOS 5.4 - it's that fine SELinux
On May 25, 2010, at 8:25 PM, Whit Blauvelt whit@transpect.com wrote:
On Tue, May 25, 2010 at 07:55:12PM -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 04:33:53PM -0700, Jerry Franz wrote:
Are you running with SELinux on?
You were right Jerry!
echo 0 > /selinux/enforce
and then /etc/init.d/smb restart works! Thank you much Jerry!
Now why doesn't that fine piece of government work, selinux, do something standard and useful like log when it's instituting breakage?? I get that it's doing it "for your own good," but what good is it if it doesn't tell you what it's doing? The _first place_ I looked when we ran into this problem was the logs. Nada. Zilch.
Programs that try to be smarter than the root user are annoying enough. Programs that do that and don't try to educate the root user while they're doing it are worse. There are standards for logging. Selinux is ignoring them. If it's going to be breaking stuff by default, and failing to log the breakage by default, that's not remotely good. Yet that's how CentOS installs it. Are we downstream of some Redhat brilliance here?
Selinux alerts are in /var/log/audit/audit.log
The problem is if smbd doesn't create the messages.tdb file then it won't have the selinux rights.
That file can be deleted and will be recreated on smbd start, it's just a cache file.
-Ross
On Tue, May 25, 2010 at 08:52:58PM -0400, Ross Walker wrote:
Selinux alerts are in /var/log/audit/audit.log
Thank you for that. Cryptic, but there it is.
The problem is if smbd doesn't create the messages.tdb file then it won't have the selinux rights.
I don't follow you. What else could have ever created the messages.tbd file? These were virgin OS installs. Whatever's in /var/cache/samba, at the time that smbd wouldn't run - which is right of the bat or at least as soon as it mattered to us, after our config was in place - is there only because either the CentOS install, or samba itself in trying to start it from /etc/init.d/smb, put it there. What else could have ever created messages.tbd than smbd?
If selinux's real complaint is that it doesn't like the files in /etc/samba being copied in from another system, that would make some sense - except that I'm not finding any mention of any of those files in the audit logs. And that still doesn't say why it starts having a problem with /var/cache/samba/messages.tbd. Does it?
That file can be deleted and will be recreated on smbd start, it's just a cache file.
So in theory if I'd nuked that file smbd would have been happy?
Then why was it also happy with "sh /etc/init.d/smb start" but not "/etc/init.d/smb start". I'm happy to become more educated on this. But if invoking a major daemon startup that selinux wants to block is as easy as that, selinux is window dressing, not security.
What am I missing about how that's anything like useful?
Regards, Whit
Whit Blauvelt wrote:
<SNIP>
Then why was it also happy with "sh /etc/init.d/smb start" but not "/etc/init.d/smb start". I'm happy to become more educated on this. But if invoking a major daemon startup that selinux wants to block is as easy as that, selinux is window dressing, not security.
What am I missing about how that's anything like useful?
As I understand it, the two different methods of invocation could involve different SELinux contexts. Under one of them the process could be less constrained than the other. If you want details, you'll have to look elsewhere, I'm just another seeker!
I've found that running the SELinux troubleshoter has been very helpful. SELinux can be a royal pain, particularly with software not written with it in mind (cough*Oracle*cougn). I try to discourage the "just turn off SELinux" mindset... it sorta reminds me of the excuses for NOT using seat belts.
In your case, there should have been AVC errors showing up in the audit log related to smbd. Using restorecon to fix up the security context on the files in /etc/samba might have resolved the issue quickly... but I guess the trick is having run across it before, eh?
"The best cure for mistakes is experience. The best source of experience is mistakes." - YMMV
On Tue, May 25, 2010 at 09:09:33PM -0500, Jay Leafey wrote:
In your case, there should have been AVC errors showing up in the audit log related to smbd. Using restorecon to fix up the security context on the files in /etc/samba might have resolved the issue quickly... but I guess the trick is having run across it before, eh?
Thoughtful advice. Thanks. Is there some method to duplicate basic configuration files across selinux servers without running restorecon for each set of files that's copied over - that is, to copy them with their selinux labels intact?
From this limited example, it looks like selinux gets in the way of standard
administrative tasks, yet wouldn't be in the way at all of anyone who'd acquired a shell within which they could run another shell and with that call whatever program they like.
I was just reading a review by Freeman Dyson of physicist Steven Weinberg's new book, Lake Views. Dyson is impressed by Weinberg's argument that for defense we often go to "glorified technologies" which don't really do for us what we expect. For example, mounted knights, which were the expensive high tech approach to war of their time, more often than not lost to peasants with pikes. The list goes on from there, right up to the present.
In it's modest way, selinux would fit right into that record. It's complex and shiney and expensive to maintain (hell, it's competitor is even called "AppArmour" - armour?). But is it as essentially useless in real combat as mounted knights were against a line of men with spears? Or as today's wishful and extravagant missile defense?
Best, Whit
On 05/25/2010 08:36 PM, Whit Blauvelt wrote:
Thoughtful advice. Thanks. Is there some method to duplicate basic configuration files across selinux servers without running restorecon for each set of files that's copied over - that is, to copy them with their selinux labels intact?
Usually if you copy them directly to their destination, they'll have the correct context. If you copy it to a different location first (like /home/) and then move it into place, it'll have the context that it got when it was created (like user_home_t).
I use bcfg2 to manage configuration files, for instance, and I don't believe that any SELinux contexts are broken as a result.
From this limited example, it looks like selinux gets in the way of standard
administrative tasks, yet wouldn't be in the way at all of anyone who'd acquired a shell within which they could run another shell and with that call whatever program they like.
No, it wouldn't, and it's not intended to. It is intended to confine your system daemons so that an attacker cannot overflow a buffer and execute arbitrary shell code (for instance).
On Tue, 2010-05-25 at 23:36 -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 09:09:33PM -0500, Jay Leafey wrote:
In your case, there should have been AVC errors showing up in the audit log related to smbd. Using restorecon to fix up the security context on the files in /etc/samba might have resolved the issue quickly... but I guess the trick is having run across it before, eh?
Thoughtful advice. Thanks. Is there some method to duplicate basic configuration files across selinux servers without running restorecon for each set of files that's copied over - that is, to copy them with their selinux labels intact?
From this limited example, it looks like selinux gets in the way of standard
administrative tasks, yet wouldn't be in the way at all of anyone who'd acquired a shell within which they could run another shell and with that call whatever program they like.
I was just reading a review by Freeman Dyson of physicist Steven Weinberg's new book, Lake Views. Dyson is impressed by Weinberg's argument that for defense we often go to "glorified technologies" which don't really do for us what we expect. For example, mounted knights, which were the expensive high tech approach to war of their time, more often than not lost to peasants with pikes. The list goes on from there, right up to the present.
In it's modest way, selinux would fit right into that record. It's complex and shiney and expensive to maintain (hell, it's competitor is even called "AppArmour" - armour?). But is it as essentially useless in real combat as mounted knights were against a line of men with spears? Or as today's wishful and extravagant missile defense?
---- you can't make a useful argument out of ignorance. If you don't want to use SELinux, then disable it. Otherwise, learn to understand how it operates and deal with it.
one certain way to cause issues with SELinux is to copy files created in other directories or other computers onto another computer because it will not have the proper security contexts so the way to fix that is to make sure your policy files are all up to date and then relabel your file system which should set the contexts to their proper labels.
Craig
you can't make a useful argument out of ignorance.
You are being religious, and wrong. See below.
If you don't want to use SELinux, then disable it.
This is a good idea. Disabling SELinux is the first thing that should be done, since (as this conversation proves plainly) what we don't know CAN hurt us, this is a useful argument arising out of ignorance.
Otherwise, learn to understand how it operates and deal with it.
SELinux should (my religion) be disabled by default, and enabled to the degree the victim err administrator understands what to expect when SELinux is enabled, and iff said administrator desires the aforehinted effects.
one certain way to cause issues with SELinux is to copy files created in other directories or other computers onto another computer because it will not have the proper security contexts so the way to fix that is to make sure your policy files are all up to date and then relabel your file system which should set the contexts to their proper labels.
My religion: 1: Disable SELinux. 2: If you think you need whatever SELinux offers, get a degree in SELinux administration sufficient to understand the ramifications of the (potential) policies. 3: Enable SELinux to the degree needed.
I've not yet seen a reason to enable SELinux. Ever. Anywhere. It is *that* badly presented to the administrators who (would) suffer it. It has (for me) broken things that were before working, it has fixed nothing that was before broken, it has been nothing but one more cadre of magicians-of-dubious-value in Pharaoh's Court.
******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On 05/26/2010 07:54 AM, Brunner, Brian T. wrote:
you can't make a useful argument out of ignorance.
You are being religious, and wrong. See below.
You also can't make a useful argument out of name-calling.
People frequently use the label "religious" derisively when someone advocates a viewpoint without cause or evidence to support it. Craig did nothing of the sort.
On 05/26/2010 07:40 AM, Craig White wrote:
you can't make a useful argument out of ignorance. If you don't want to use SELinux, then disable it. Otherwise, learn to understand how it operates and deal with it.
one certain way to cause issues with SELinux is to copy files created in other directories or other computers onto another computer because it will not have the proper security contexts so the way to fix that is to make sure your policy files are all up to date and then relabel your file system which should set the contexts to their proper labels.
I can make a useful argument from experience. Over the last few years, as Redhat has progressively deployed SELinux, I have had *several* incidents (the most recent only a few weeks ago) where updates to SELinux broke existing, stable, systems. Each time sucking up hours of my time to diagnose and fix. And (as in this incident) there are not always useful error messages to track it with.
The *theoretical* system security improvement of SELinux is trumped by the *practical* observation that I have had existing systems broken by SELinux multiple times on the mere handful of systems I have run it on in enforcing mode, but have yet to see a single one of several dozen (all internet exposed) up-to-date *non*-SELinux systems hacked.
It is a 'safety' feature that is in practice more dangerous to system stability than what it is trying to fix. It is like having air bags in your car that go off at random times while you are driving: It is NOT acceptable behavior.
Benjamin wrote:
On 05/26/2010 07:40 AM, Craig White wrote:
you can't make a useful argument out of ignorance. If you don't want to use SELinux, then disable it. Otherwise, learn to understand how it operates and deal with it.
one certain way to cause issues with SELinux is to copy files created in other directories or other computers onto another computer because it will not have the proper security contexts so the way to fix that is to make sure your policy files are all up to date and then relabel your file system which should set the contexts to their proper labels.
I can make a useful argument from experience. Over the last few years, as Redhat has progressively deployed SELinux, I have had *several* incidents (the most recent only a few weeks ago) where updates to SELinux broke existing, stable, systems. Each time sucking up hours of my time to diagnose and fix. And (as in this incident) there are not always useful error messages to track it with.
<snip> And the selinux folks (I'm on the fedora selinux mailing list) don't like to accept that *they* have bugs. For example, we're stuck with CA's siteminder (*gag*). Selinux complains about it writing to its own logfile, /var/log/httpd/smwagent.log. The AVI, when I run sealert, tells me to fix it by setting httpd_unified to on. I've done that, numerous times, which tells me that *they* have a logical flaw in their error handling, and it's *not* telling me the correct cause/solution.
They didn't suggest I file a bug report when I mentioned it on the list. Maybe I'll do it again....
mark
The *theoretical* system security improvement of SELinux is trumped by the *practical* observation that I have had existing systems broken by SELinux multiple times on the mere handful of systems I have run it on in enforcing mode, but have yet to see a single one of several dozen (all internet exposed) up-to-date *non*-SELinux systems hacked.
It is a 'safety' feature that is in practice more dangerous to system stability than what it is trying to fix. It is like having air bags in your car that go off at random times while you are driving: It is NOT acceptable behavior.
Under CentOS 5.5, and I presume RHEL5.5 too, there is a small improvement in the shape of setroubleshoot-server, it at least gives you improved troubleshooting capabilities.
Not that it helps when you upgrade a 5.4 machine to 5.5 and you get no selinux logging whatsoever because setroubleshoot-server wasn't installed during the upgrade. Note to self, need to add it to the minimal-kickstart configurations.
--------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---------------------------------------------------------------
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
I can make a useful argument from experience. Over the last few years, as Redhat has progressively deployed SELinux, I have had *several* incidents (the most recent only a few weeks ago) where updates to SELinux broke existing, stable, systems. Each time sucking up hours of my time to diagnose and fix. And (as in this incident) there are not always useful error messages to track it with.
Except that in this incident, there WERE useful error messages. The OP simply didn't know that he needed to look in /var/log/audit/audit.log.
The *theoretical* system security improvement of SELinux is trumped by the *practical* observation that I have had existing systems broken by SELinux multiple times on the mere handful of systems I have run it on in enforcing mode, but have yet to see a single one of several dozen (all internet exposed) up-to-date *non*-SELinux systems hacked.
You are comparing two unlike things. You can't very well judge the benefits of SELinux based on a system which hasn't needed its protection.
It is a 'safety' feature that is in practice more dangerous to system stability than what it is trying to fix.
I advise administrators to test all updates on non-production systems. SELinux updates are no exception.
On 05/26/2010 08:23 PM, Gordon Messmer wrote:
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
[...]
The *theoretical* system security improvement of SELinux is trumped by the *practical* observation that I have had existing systems broken by SELinux multiple times on the mere handful of systems I have run it on in enforcing mode, but have yet to see a single one of several dozen (all internet exposed) up-to-date *non*-SELinux systems hacked.
You are comparing two unlike things. You can't very well judge the benefits of SELinux based on a system which hasn't needed its protection.
I'm comparing a simple metric that applies to *ANY* system admin job:
(Downtime) / (Machines * Years)
The metric *DOESN'T CARE* if that downtime is because of bad power, hard drive crashes, hackers, cosmic rays, SELinux, or poor admining.
It cares that the services are offline, on how many machines and for how long.
Arguing that I'm comparing apple and oranges is like claiming that (using my analogy of faulty air bags again) it isn't *meaningful* for me to say that faulty airbags that go off randomly while driving is a bigger hazard than car accidents for me because I haven't had any car crashes specifically needing air bags: The airbag going off randomly while I'm driving is very likely to *cause* a serious car accident itself. I'm measuring *all* serious accidents - not just 'accidents where the airbag might have gone off'.
A 'safety feature' that *causes* more damage than it prevents isn't a safety feature - it's a hazard. And on otherwise properly maintained systems, SELinux is a hazard.
It is a 'safety' feature that is in practice more dangerous to system stability than what it is trying to fix.
I advise administrators to test all updates on non-production systems. SELinux updates are no exception. ______________________________________
I have *twenty* virtual machines I deploy updates to before it ever touches my production systems. Not everything is testable on non-production machines. Nor, as the system admin, senior programmer and desktop support person for the entire company do I have the sheer time needed to test every sub-system before deployment. And I shouldn't damn well *need* to on a normal system update to an Enterprise grade distribution (I'm not knocking the CentOS team here - this is about Redhat and SELinux).
SELinux makes my systems significantly *LESS* reliable instead of *MORE* reliable. And that is a bad thing.
Now back to fixing the SELinux configuration on a machine I had to put in 'permissive' mode a few weeks ago because the last round of SELinux updates broke the web server's ability to open its own log files. That is what I still have left to fix after having to relabel the entire system to fix the other breakages the update introduced. And no - I'm not kidding or making things up.
On Thu, 2010-05-27 at 05:55 -0700, Jerry Franz wrote:
On 05/26/2010 08:23 PM, Gordon Messmer wrote:
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
[...]
The *theoretical* system security improvement of SELinux is trumped by the *practical* observation that I have had existing systems broken by SELinux multiple times on the mere handful of systems I have run it on in enforcing mode, but have yet to see a single one of several dozen (all internet exposed) up-to-date *non*-SELinux systems hacked.
You are comparing two unlike things. You can't very well judge the benefits of SELinux based on a system which hasn't needed its protection.
I'm comparing a simple metric that applies to *ANY* system admin job:
(Downtime) / (Machines * Years)The metric *DOESN'T CARE* if that downtime is because of bad power, hard drive crashes, hackers, cosmic rays, SELinux, or poor admining.
It cares that the services are offline, on how many machines and for how long.
Arguing that I'm comparing apple and oranges is like claiming that (using my analogy of faulty air bags again) it isn't *meaningful* for me to say that faulty airbags that go off randomly while driving is a bigger hazard than car accidents for me because I haven't had any car crashes specifically needing air bags: The airbag going off randomly while I'm driving is very likely to *cause* a serious car accident itself. I'm measuring *all* serious accidents - not just 'accidents where the airbag might have gone off'.
A 'safety feature' that *causes* more damage than it prevents isn't a safety feature - it's a hazard. And on otherwise properly maintained systems, SELinux is a hazard.
It is a 'safety' feature that is in practice more dangerous to system stability than what it is trying to fix.
I advise administrators to test all updates on non-production systems. SELinux updates are no exception. ______________________________________
I have *twenty* virtual machines I deploy updates to before it ever touches my production systems. Not everything is testable on non-production machines. Nor, as the system admin, senior programmer and desktop support person for the entire company do I have the sheer time needed to test every sub-system before deployment. And I shouldn't damn well *need* to on a normal system update to an Enterprise grade distribution (I'm not knocking the CentOS team here - this is about Redhat and SELinux).
SELinux makes my systems significantly *LESS* reliable instead of *MORE* reliable. And that is a bad thing.
Now back to fixing the SELinux configuration on a machine I had to put in 'permissive' mode a few weeks ago because the last round of SELinux updates broke the web server's ability to open its own log files. That is what I still have left to fix after having to relabel the entire system to fix the other breakages the update introduced. And no - I'm not kidding or making things up.
---- I guess I don't understand because I have not had to relabel entire filesystems unless I have disabled SELinux and have never experienced an update that 'broke' things on CentOS (Fedora is a different issue but that is more experimental).
Most of the people I see griping about SElinux just don't want to be bothered with it and just turn it off or they are forced to use it and don't spend the time learning the tools. It's relatively simple to set file contexts or policy and I just don't see the downtime being a factor anywhere.
Craig
On 05/27/2010 05:55 AM, Jerry Franz wrote:
I have *twenty* virtual machines I deploy updates to before it ever touches my production systems. Not everything is testable on non-production machines.
...
Now back to fixing the SELinux configuration on a machine I had to put in 'permissive' mode a few weeks ago because the last round of SELinux updates broke the web server's ability to open its own log files.
That sounds like the sort of thing that you'd have noticed if you'd applied the update and started the service on a test host before production.
On 05/27/2010 08:51 AM, Gordon Messmer wrote:
On 05/27/2010 05:55 AM, Jerry Franz wrote:
I have *twenty* virtual machines I deploy updates to before it ever touches my production systems. Not everything is testable on non-production machines.
...
Now back to fixing the SELinux configuration on a machine I had to put in 'permissive' mode a few weeks ago because the last round of SELinux updates broke the web server's ability to open its own log files.
That sounds like the sort of thing that you'd have noticed if you'd applied the update and started the service on a test host before production.
I have finite resources.
If I had junior admins who could spend weeks doing testing of every update before deployment, twice as many physical machines as I now have so I could deploy dozens of VMs _just for testing updates_ (and let's not even begin to discuss the non-virtualizable machines such as the backups storage servers) , an extra co-location rack to put those additional servers in, and the budget to fix any emergent SELinux breakage, then, yeah, that would work. At a net cost several times higher than my current budget.
Or I can turn off SELinux on most of my systems and not get my systems gratuitously broken every few to several months by SELinux policy updates. For my current budget.
Hmmm.... What to do... What to do....
On May 25, 2010, at 9:44 PM, Whit Blauvelt whit@transpect.com wrote:
On Tue, May 25, 2010 at 08:52:58PM -0400, Ross Walker wrote:
Selinux alerts are in /var/log/audit/audit.log
Thank you for that. Cryptic, but there it is.
The problem is if smbd doesn't create the messages.tdb file then it won't have the selinux rights.
I don't follow you. What else could have ever created the messages.tbd file? These were virgin OS installs. Whatever's in /var/cache/samba, at the time that smbd wouldn't run - which is right of the bat or at least as soon as it mattered to us, after our config was in place - is there only because either the CentOS install, or samba itself in trying to start it from /etc/init.d/smb, put it there. What else could have ever created messages.tbd than smbd?
I was under the impression that the config might have been copied in including what might be in /var/cache/samba, but if it wasn't then maybe it was the joining the machine to the domain, which also creates a messages.tdb file.
If selinux's real complaint is that it doesn't like the files in / etc/samba being copied in from another system, that would make some sense - except that I'm not finding any mention of any of those files in the audit logs. And that still doesn't say why it starts having a problem with /var/cache/samba/messages.tbd. Does it?
Best guess is joining the machine to the domain under root context caused the cache files to be created under the root context.
That file can be deleted and will be recreated on smbd start, it's just a cache file.
So in theory if I'd nuked that file smbd would have been happy?
Yup, in fact I don't know why the cache files that don't need to persist aren't removed on service shutdown.
Then why was it also happy with "sh /etc/init.d/smb start" but not "/etc/init.d/smb start". I'm happy to become more educated on this. But if invoking a major daemon startup that selinux wants to block is as easy as that, selinux is window dressing, not security.
When passing the script into a shell run under root context the script was actually run under root context, when executing the script directly (invoking the shell indirectly) it ran under smbd context.
Selinux is there to help prevent what happens within a security context, but running things as root can accidentally elevate a program's context.
Maybe sudo can help here?
What am I missing about how that's anything like useful?
Selinux is a strange beast, but it's one of those things once you set it right you can pretty much forget it.
-Ross
On 05/25/2010 06:44 PM, Whit Blauvelt wrote:
And that still doesn't say why it starts having a problem with /var/cache/samba/messages.tbd. Does it?
That's simply the first file which was denied by policy. If that one had been removed, the next one would have caused problems.
That file can be deleted and will be recreated on smbd start, it's just a cache file.
So in theory if I'd nuked that file smbd would have been happy?
No. With that file removed, smbd probably wouldn't have been able to write to the directory. If it was able to, it probably would have run into trouble with the next file. If smbd started up in the context which was configured for it, everything would work normally. If smbd started up in the "unconfined" context, everything would work normally (but not benefit from SELinux security). The problem appears to be that smbd was starting in some other context, which you haven't shared.
Then why was it also happy with "sh /etc/init.d/smb start" but not "/etc/init.d/smb start". I'm happy to become more educated on this. But if invoking a major daemon startup that selinux wants to block is as easy as that, selinux is window dressing, not security.
Your misunderstanding seems to be that SELinux is not intended to prevent an attacker who has root privileges on your system from starting smbd. Instead, it is intended to confine the smbd that the system's administrator is running from taking actions which are not allowed by policy.
That is to say that SELinux does not "want" to block smbd from running. SELinux is intended to describe the access that system daemons like smbd should have in greater detail than mere filesystem access, and to confine smbd to that behavior. Whatever you did caused smbd to start up in some other context (but not unconfined), and was thus confining smbd to the behavior that was appropriate for some other process. It should be obvious why that would cause problems.
Gordon Messmer wrote:
No. With that file removed, smbd probably wouldn't have been able to write to the directory. If it was able to, it probably would have run into trouble with the next file. If smbd started up in the context which was configured for it, everything would work normally. If smbd started up in the "unconfined" context, everything would work normally (but not benefit from SELinux security). The problem appears to be that smbd was starting in some other context, which you haven't shared.
Then why was it also happy with "sh /etc/init.d/smb start" but not "/etc/init.d/smb start". I'm happy to become more educated on this. But if invoking a major daemon startup that selinux wants to block is as easy as that, selinux is window dressing, not security.
Your misunderstanding seems to be that SELinux is not intended to prevent an attacker who has root privileges on your system from starting smbd. Instead, it is intended to confine the smbd that the system's administrator is running from taking actions which are not allowed by policy.
That still doesn't explain why there is a difference in smbd's context when its parent is an explicitly started shell vs. the implict one that starts when the script file is executed. Isn't the context associated with the program itself, not its parent? Is this documented anywhere?
That is to say that SELinux does not "want" to block smbd from running. SELinux is intended to describe the access that system daemons like smbd should have in greater detail than mere filesystem access, and to confine smbd to that behavior. Whatever you did caused smbd to start up in some other context (but not unconfined), and was thus confining smbd to the behavior that was appropriate for some other process. It should be obvious why that would cause problems.
From what he has posted so far the "whatever he did" was starting smbd directly from a root command line or running the init script with 'sh' or 'bash'. Why would that give a different context than running the init script with the sh.
On May 26, 2010, at 1:44 AM, Les Mikesell lesmikesell@gmail.com wrote:
Gordon Messmer wrote:
No. With that file removed, smbd probably wouldn't have been able to write to the directory. If it was able to, it probably would have run into trouble with the next file. If smbd started up in the context which was configured for it, everything would work normally. If smbd started up in the "unconfined" context, everything would work normally (but not benefit from SELinux security). The problem appears to be that smbd was starting in some other context, which you haven't shared.
Then why was it also happy with "sh /etc/init.d/smb start" but not "/etc/init.d/smb start". I'm happy to become more educated on this. But if invoking a major daemon startup that selinux wants to block is as easy as that, selinux is window dressing, not security.
Your misunderstanding seems to be that SELinux is not intended to prevent an attacker who has root privileges on your system from starting smbd. Instead, it is intended to confine the smbd that the system's administrator is running from taking actions which are not allowed by policy.
That still doesn't explain why there is a difference in smbd's context when its parent is an explicitly started shell vs. the implict one that starts when the script file is executed. Isn't the context associated with the program itself, not its parent? Is this documented anywhere?
That is to say that SELinux does not "want" to block smbd from running. SELinux is intended to describe the access that system daemons like smbd should have in greater detail than mere filesystem access, and to confine smbd to that behavior. Whatever you did caused smbd to start up in some other context (but not unconfined), and was thus confining smbd to the behavior that was appropriate for some other process. It should be obvious why that would cause problems.
From what he has posted so far the "whatever he did" was starting smbd directly from a root command line or running the init script with 'sh' or 'bash'. Why would that give a different context than running the init script with the sh.
These are excellent questions that I wish I knew. I suspect it all has to do with how selinux associates processes with security contexts, but if someone has a pointer to the details already at hand that would be nice.
-Ross
On 05/25/2010 10:44 PM, Les Mikesell wrote:
That still doesn't explain why there is a difference in smbd's context when its parent is an explicitly started shell vs. the implict one that starts when the script file is executed.
SELinux domain transitions are handled by the kernel. If you call exec() with a path which has a domain transition specified, the kernel will transition to the specified domain as part of the exec() call.
What that means here is that /etc/init.d/smbd has a domain transition specified. If you were to call exec() with that path (as your shell will when you enter that path alone and hit Enter), the kernel receives your exec() request, examines the path given, determines that a transition is defined, and transitions to the new domain as it creates the new process.
Now, if you call exec() with /bin/sh as the path and /etc/init.d/smbd as an arg (as your shell will when you enter "/bin/sh /etc/init.d/smbd" and hit Enter), the kernel will check for a domain transition on /bin/sh and load that program. The kernel has no knowledge that sh will load instructions from /etc/init.d/smbd and execute them any more than it would if you were to run "/bin/sh < /etc/init.d/smbd" in a shell. It can't determine that it should transition to the domain on that file, so the process inherits whatever domain called "/bin/sh" (probably the unconfined domain).
Isn't the context associated with the program itself, not its parent?
The context is inherited from the process which calls exec() if there is no transition defined. If there is a transition, it is associated with the path.
Is this documented anywhere?
Yes, this is the documented behavior of domain transitions.
That is to say that SELinux does not "want" to block smbd from running. SELinux is intended to describe the access that system daemons like smbd should have in greater detail than mere filesystem access, and to confine smbd to that behavior. Whatever you did caused smbd to start up in some other context (but not unconfined), and was thus confining smbd to the behavior that was appropriate for some other process. It should be obvious why that would cause problems.
From what he has posted so far the "whatever he did" was starting smbd directly from a root command line or running the init script with 'sh' or 'bash'.
I meant whatever he did to create /etc/init.d/smbd with an SELinux label other than the one that rpm originally placed on it. He wasn't specific about how or where the file was created. It had a label on it which caused a transition to an SELinux domain other than unconfined or the one normally used by smbd.
On 5/26/2010 5:16 PM, Gordon Messmer wrote:
Isn't the context associated with the program itself, not its parent?
The context is inherited from the process which calls exec() if there is no transition defined. If there is a transition, it is associated with the path.
Is this documented anywhere?
Yes, this is the documented behavior of domain transitions.
I meant, is it documented that the domain transitions are specified on the init scripts only, not the actual programs they start? Or is that a quirk of this particular case? It's not unusual at all for an administrator to run the init scripts directly, perhaps with 'sh -x' to see the values that are expanded in the commands. I doubt if many people that trust SElinux would realize that would leave them unprotected.
That is to say that SELinux does not "want" to block smbd from running. SELinux is intended to describe the access that system daemons like smbd should have in greater detail than mere filesystem access, and to confine smbd to that behavior. Whatever you did caused smbd to start up in some other context (but not unconfined), and was thus confining smbd to the behavior that was appropriate for some other process. It should be obvious why that would cause problems.
From what he has posted so far the "whatever he did" was starting smbd directlyfrom a root command line or running the init script with 'sh' or 'bash'.
I meant whatever he did to create /etc/init.d/smbd with an SELinux label other than the one that rpm originally placed on it. He wasn't specific about how or where the file was created. It had a label on it which caused a transition to an SELinux domain other than unconfined or the one normally used by smbd.
My impression was that the usual invocation of /etc/init.d/smbd (via "service" or directly without 'sh ...' _did_ give the expected context and his problems were from files smbd subsequently could not access, whereas running smbd directly or using 'sh ' on the script made it work anyway.
-
Benjamin Franz -
Brunner, Brian T. -
Craig White -
Gordon Messmer -
Jay Leafey -
Jerry Franz
-
Lars Hecking -
Les Mikesell -
m.roth＠5-cent.us -
Ross Walker -
Whit Blauvelt