On Thu, 2008-01-03 at 14:08 -0500, Eric Paris wrote:
Can you show me more of the log?
The log is more sgrubb.
I think selinux-policy is busted at the moment. depmod and mkinitrd are having trouble in enforcing...
rpm -e kernel-2.6.24-133-blah-blah setenforce 0 yum update kernel setenforce 1
if that fixes it blame selinux
Also get the same result if you don't have your storage driver in /etc/modprobe.conf so you can look there first...
I'm not running SELinux enforcing mode on any of my machines..
David
On Thursday 03 January 2008 14:10:20 David Zeuthen wrote:
Can you show me more of the log?
The log is more sgrubb.
Eh.. From.. the log is from sgrubb. That's what I meant.
Turns out the problem shows up on my laptop. I started to hook up a serial cable and found doesn't have a serial port. I thought it did...so no logs.
-Steve
On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote:
I'm not running SELinux enforcing mode on any of my machines..
That's too bad -- it's hard to gage the usability of a system without it on, since it is enabled by default for most people.
On Thu, 2008-01-03 at 14:45 -0500, Dimi Paun wrote:
On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote:
I'm not running SELinux enforcing mode on any of my machines..
That's too bad -- it's hard to gage the usability of a system without it on, since it is enabled by default for most people.
Well, the kernel bits of SELinux is great. The user space bits never ever worked for me; neither as a user, nor RPM package maintainer and definitely not as an upstream developer of highly modular software that is designed to be locked down (e.g. hald and it's helper processes)
Some problems from a 50,000 feet point of view
- the policy is way too complicated; really, I think it's kinda futile, at this point, to attempt to lock down bits that are not even network-facing.
As a result someone decided "oh, we're just going to let people turn of it". And this is where we are now. Total cop out. Might as well not ship it.
Seriously. Just go ahead and look at the policy. No wonder it often doesn't work given it's so complex.
- the policy is centrally maintained; e.g. the maintainer of the policy for hald (Dan Walsh) and, hey, all of the policy often have to guess how to lock things down and often, despite Dan being a great engineer, these guesses are just wrong. Seriously, no one can blame Dan for this - you cannot expect a single person to know all the kinks of all the software in Fedora.
-> Ideally every upstream project can maintain it's own policy. That has the nice side effect of, gosh, teaching other distributions about the benefits of MCA.
-> If upstream don't want to include SELinux policy, just include it as a patch in the RPM
Typical responses: - "rpm cannot handle SELinux policy": <- bullshit; it's not much different from other file meta data; do we store file modes and permissions centrally too? No.
- "uh, then you would have deps on policy": Like, for example, the policy for hald would depend on the policy for, say, dbus. Not a problem, the real world contains dependencies already and most these deps are handled just fine already by the upstream projects.
I'm not even going to go into the language used for defining policy.
In short, SELinux just doesn't work for me. I'm not denying it may work well on a tightly-controlled servers where features never change (e.g. RHEL).
David
On Thu, 2008-01-03 at 15:43 -0500, David Zeuthen wrote:
-> Ideally every upstream project can maintain it's own policy. That has the nice side effect of, gosh, teaching other distributions about the benefits of MCA.
Eh, MAC. As in Mandatory Access Control. Guess I got too carried away in my rant. I'm OK now!
David
On Thu, 03 Jan 2008 15:43:26 -0500 David Zeuthen david@fubar.dk wrote:
Typical responses: - "rpm cannot handle SELinux policy": <- bullshit; it's not much different from other file meta data; do we store file modes and permissions centrally too? No.
I don't know where you're getting this "typical" response from. The problem isn't rpm, the problem is selinux itself, not allowing rpm to write out files that have a context it doesn't know about (yet), since the context may be in the policy it's laying down. Think chroots or anaconda or livecreation. Until the selinux upstream gets a clue on this one we're stuck. It's not like people haven't been arguing this point for many many years now...
On Thu, 2008-01-03 at 15:48 -0500, Jesse Keating wrote:
On Thu, 03 Jan 2008 15:43:26 -0500 David Zeuthen david@fubar.dk wrote:
Typical responses: - "rpm cannot handle SELinux policy": <- bullshit; it's not much different from other file meta data; do we store file modes and permissions centrally too? No.
I don't know where you're getting this "typical" response from. The problem isn't rpm, the problem is selinux itself, not allowing rpm to write out files that have a context it doesn't know about (yet), since the context may be in the policy it's laying down. Think chroots or anaconda or livecreation. Until the selinux upstream gets a clue on this one we're stuck. It's not like people haven't been arguing this point for many many years now...
Sure, granted. I wasn't really ranting at the .rpm or .deb people here.
(However, no one prevents you from using SELinux in permissive mode during installs or live cd creation and then relabel the fs at the end. Heck at least for the latter I'm pretty sure you can't even use enforcing mode because the SELinux policy is so draconian as part of it's complexity)
David
On Thu, 03 Jan 2008 15:56:22 -0500 David Zeuthen david@fubar.dk wrote:
Sure, granted. I wasn't really ranting at the .rpm or .deb people here.
(However, no one prevents you from using SELinux in permissive mode during installs or live cd creation and then relabel the fs at the end. Heck at least for the latter I'm pretty sure you can't even use enforcing mode because the SELinux policy is so draconian as part of it's complexity)
Yeah, we have to use permissive at least, or else things fail.
On Thu, 2008-01-03 at 15:48 -0500, Jesse Keating wrote:
On Thu, 03 Jan 2008 15:43:26 -0500 David Zeuthen david@fubar.dk wrote:
Typical responses: - "rpm cannot handle SELinux policy": <- bullshit; it's not much different from other file meta data; do we store file modes and permissions centrally too? No.
I don't know where you're getting this "typical" response from. The problem isn't rpm, the problem is selinux itself, not allowing rpm to write out files that have a context it doesn't know about (yet),
Also, one obvious solution here is to install the selinux policy before files are copied; much like you create a daemon user in %pre. Or if %pre isn't early enough, invent another tag or whatever. Point is: you can't entirely blame this on the SELinux people; getting things like rpm to work with selinux actually requires a two-way conversation - something that some companies can't figure out to make happen :-/
David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Zeuthen wrote:
On Thu, 2008-01-03 at 14:45 -0500, Dimi Paun wrote:
On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote:
I'm not running SELinux enforcing mode on any of my machines..
That's too bad -- it's hard to gage the usability of a system without it on, since it is enabled by default for most people.
Well, the kernel bits of SELinux is great. The user space bits never ever worked for me; neither as a user, nor RPM package maintainer and definitely not as an upstream developer of highly modular software that is designed to be locked down (e.g. hald and it's helper processes)
Some problems from a 50,000 feet point of view
the policy is way too complicated; really, I think it's kinda futile, at this point, to attempt to lock down bits that are not even network-facing.
As a result someone decided "oh, we're just going to let people turn of it". And this is where we are now. Total cop out. Might as well not ship it.
Seriously. Just go ahead and look at the policy. No wonder it often doesn't work given it's so complex.
the policy is centrally maintained; e.g. the maintainer of the policy for hald (Dan Walsh) and, hey, all of the policy often have to guess how to lock things down and often, despite Dan being a great engineer, these guesses are just wrong. Seriously, no one can blame Dan for this - you cannot expect a single person to know all the kinks of all the software in Fedora.
-> Ideally every upstream project can maintain it's own policy. That has the nice side effect of, gosh, teaching other distributions about the benefits of MCA.
-> If upstream don't want to include SELinux policy, just include it as a patch in the RPM
Typical responses:
"rpm cannot handle SELinux policy": <- bullshit; it's not much different from other file meta data; do we store file modes and permissions centrally too? No.
"uh, then you would have deps on policy": Like, for example, the policy for hald would depend on the policy for, say, dbus. Not a problem, the real world contains dependencies already and most these deps are handled just fine already by the upstream projects.
I'm not even going to go into the language used for defining policy.
In short, SELinux just doesn't work for me. I'm not denying it may work well on a tightly-controlled servers where features never change (e.g. RHEL).
David
Well there are several problems with allowing the individual maintainers manage their own policy.
#1 they won't. #2 when they do, they do a very bad job of it. Or basically just end up with unconfined_t. #3 The tools are too slow. Having 100 semodule -i will cause the installation to take for ever. #4 Interaction between confined domains does not work well when multiple maintainers writing policy. sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, pyzor ... All interact in very complex ways. #5 conflicts on file_context directories/files
David, You are writing an application that is trying to do things on behalf of the user as root. These activities will cause conflicts and need to be well controlled. So you are likely to run into problems with SELinux.
Jesse, what problems are you seeing that needs to run in permissive mode? I know about the chroot environments and there is not a good answer to this. Placing of the file context down without loading the SELInux policy would help in this environment. But we would still have problems with applications running in post install, not getting the correct context.
On Thu, 03 Jan 2008 17:07:33 -0500 Daniel J Walsh dwalsh@redhat.com wrote:
Jesse, what problems are you seeing that needs to run in permissive mode? I know about the chroot environments and there is not a good answer to this. Placing of the file context down without loading the SELInux policy would help in this environment. But we would still have problems with applications running in post install, not getting the correct context.
What I've seen is if selinux is in enforcing part of the compose process will fail in such a way that selinux will default to /off/ for the resulting composed media (funny eh?). I think it had something to do with a denial, but the memory is hazy. But since most of my composing involves A) mock for the initial compose environment (that's one chroot) and B) buildinstall itself creating an install root to populate stage1/2 contents (that's two chroots) I kind of feel I'm out in left field.
On Thu, 2008-01-03 at 17:07 -0500, Daniel J Walsh wrote:
Well there are several problems with allowing the individual maintainers manage their own policy.
#1 they won't. #2 when they do, they do a very bad job of it. Or basically just end up with unconfined_t. #3 The tools are too slow. Having 100 semodule -i will cause the installation to take for ever. #4 Interaction between confined domains does not work well when multiple maintainers writing policy. sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, pyzor ... All interact in very complex ways. #5 conflicts on file_context directories/files
See.. cause and effect.. #1 and #2 are the effects of #3 and the fact that the policy is way too big and the whole system is way too complicated.
Besides.. I have asked probably more than ten times (both electronically and in person) about maintaining the selinux policy for hal in the _upstream_ tarball but I've always been told that it's not possible or I've been told to wait. In the meantime it's business as usual; things are broken and people turn off SELinux.
Here's a challenge: Send me a patch against the hal git repo and the RPM spec with the SELinux bits... Then I'll be happy to maintain it; including spending time on learning SELinux well enough to do a good job. Is this even possible? Should it be possible?
David, You are writing an application that is trying to do things on behalf of the user as root. These activities will cause conflicts and need to be well controlled. So you are likely to run into problems with SELinux.
Sigh. Do you really honestly think this is a good answer for upstream maintainers that are _willing_ to help?
David
On Thursday 03 January 2008 17:46:51 David Zeuthen wrote:
#1 they won't. #2 when they do, they do a very bad job of it. Or basically just end up with unconfined_t. #3 The tools are too slow. Having 100 semodule -i will cause the installation to take for ever. #4 Interaction between confined domains does not work well when multiple maintainers writing policy. sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, pyzor ... All interact in very complex ways. #5 conflicts on file_context directories/files
See.. cause and effect.. #1 and #2 are the effects of #3
I don't think this is true at all. semodule being slow has nothing to do with people thinking about security. It takes time and testing a lot of variations of config options to arrive at what the application is supposed to do. Some people also may not recognize when an avc means the code needs to change instead of allowing the behavior.
I think that #4 is the real killer. Dan did a major reworking of policy in F8 to merge what was the strict policy with targeted. The way that roles work was beefed up. If this had to be coordinated with every single package maintainer, it probably wouldn't have gotten done as quickly or as uniformly.
and the fact that the policy is way too big and the whole system is way too complicated.
This is more a fact of it telling you that software in general is complicated. SE Linux is describing the allowed behavior at a level that is slightly above the syscall level. If the syscalls a program makes change, the policy may need reworking.
This is probably why you run into problems frequently as you are developing and testing new code (with new syscalls) that is central to many programs.
I wonder if a tool could be developed to do something like nmap and compare current syscalls with an older version. It wouldn't be able to track resource usage (files/sockets), which is another thing selinux regulates, but it could tell you a little about if a new version is going to have problems. If we could simply tell that a new package required policy changes, that would be half the battle.
-Steve
Steve Grubb wrote:
I wonder if a tool could be developed to do something like nmap and compare current syscalls with an older version. It wouldn't be able to track resource usage (files/sockets), which is another thing selinux regulates, but it could tell you a little about if a new version is going to have problems. If we could simply tell that a new package required policy changes, that would be half the battle.
I don't know if that would be possible, but I think that would be beneficial and expedite getting the correct policy changes in place for testing updates as well as new packages. One major issue with testing these packages with enforced selinux is that you often cannot get the program to operate even enough to 'test' it, and it can take quite awhile to get the policy change so you can then continue trying enforcing mode. That tiring cycle is probably why so many testers just toggle it off, and then it just takes longer to find all the denials for test packages.
I suppose the maintainer just doing a cursory selinux test of their own before getting package builds dropped into rawhide might help... I'm sure many do but it would seem that some don't. Just getting a BZ filed with the denials asap is important.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Zeuthen wrote:
On Thu, 2008-01-03 at 17:07 -0500, Daniel J Walsh wrote:
Well there are several problems with allowing the individual maintainers manage their own policy.
#1 they won't. #2 when they do, they do a very bad job of it. Or basically just end up with unconfined_t. #3 The tools are too slow. Having 100 semodule -i will cause the installation to take for ever. #4 Interaction between confined domains does not work well when multiple maintainers writing policy. sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, pyzor ... All interact in very complex ways. #5 conflicts on file_context directories/files
See.. cause and effect.. #1 and #2 are the effects of #3 and the fact that the policy is way too big and the whole system is way too complicated.
Besides.. I have asked probably more than ten times (both electronically and in person) about maintaining the selinux policy for hal in the _upstream_ tarball but I've always been told that it's not possible or I've been told to wait. In the meantime it's business as usual; things are broken and people turn off SELinux.
Here's a challenge: Send me a patch against the hal git repo and the RPM spec with the SELinux bits... Then I'll be happy to maintain it; including spending time on learning SELinux well enough to do a good job. Is this even possible? Should it be possible?
David, You are writing an application that is trying to do things on behalf of the user as root. These activities will cause conflicts and need to be well controlled. So you are likely to run into problems with SELinux.
Sigh. Do you really honestly think this is a good answer for upstream maintainers that are _willing_ to help?
David
I have build a spec file and included the current rawhide sources for both policy kit and hal. As soon as you are ready to ship them I will move them to update status in the selinux-policy package.
If you need help building the policy or writing policy, please you know how to reach me. :^)
If other maintainers are interested in shipping their own policy, I will make it available.
Dan
-
Andrew Farris -
Daniel J Walsh -
David Zeuthen -
David Zeuthen -
Dimi Paun -
Jesse Keating -
Steve Grubb