When I install the selinux-policy-targeted rpm in a chroot it seems that load_policy is executed and loads the policy that's installed in the chroot into the running kernel (I'm assuming via %post). Should installing the selinux-policy-targeted rpm in a chroot allow this to happen? What if you're installing a policy into the chroot that's different than the one you have installed on your system? Is there a way to not allow load_policy to execute in a chroot?
Here is the AVC messages I'm getting:
Jan 8 21:38:23 chaucer kernel: audit(1105249103.605:0): avc: granted { load_policy } for pid=4233 exe=/usr/sbin/load_policy scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security Jan 8 21:38:23 chaucer kernel: security: 3 users, 4 roles, 316 types, 20 bools Jan 8 21:38:23 chaucer kernel: security: 53 classes, 7962 rules
Bob
On Sat, 08 Jan 2005 21:55:07 PST, Bob Kashani said:
When I install the selinux-policy-targeted rpm in a chroot it seems that load_policy is executed and loads the policy that's installed in the chroot into the running kernel (I'm assuming via %post). Should installing the selinux-policy-targeted rpm in a chroot allow this to happen? What if you're installing a policy into the chroot that's different than the one you have installed on your system? Is there a way to not allow load_policy to execute in a chroot?
In general, there's not much way to distinguish "in a chroot". The "SELinux Way" to address this is to make sure that all files on the system that can legitimately be loaded as policy are flagged with a context that allows loading them. If there's nothing in the chroot with the appropriate context, it can't load it.
I notice yours is flagged as 'unconfined_t', which smells a lot like running the targeted policy. The design point for that policy is "constrain certain daemons, but assume that users are in general trusted and know what they're doing". As such, it's assuming that if you're loading the policy from a chroot that you know what you're doing and should be allowed to do so. If that doesn't describe how you want things to work, maybe you should be running 'strict' instead of 'targeted'?
On Sun, 2005-01-09 at 01:20 -0500, Valdis.Kletnieks@vt.edu wrote:
I notice yours is flagged as 'unconfined_t', which smells a lot like running the targeted policy. The design point for that policy is "constrain certain daemons, but assume that users are in general trusted and know what they're doing". As such, it's assuming that if you're loading the policy from a chroot that you know what you're doing and should be allowed to do so. If that doesn't describe how you want things to work, maybe you should be running 'strict' instead of 'targeted'?
I actually like the flexibility of targeted and I tried strict yesterday and it causes my system to hang. When I do get the chance I will play around with strict though.
Bob
On Sat, 2005-01-08 at 21:55 -0800, Bob Kashani wrote:
When I install the selinux-policy-targeted rpm in a chroot it seems that load_policy is executed and loads the policy that's installed in the chroot into the running kernel (I'm assuming via %post). Should installing the selinux-policy-targeted rpm in a chroot allow this to happen? What if you're installing a policy into the chroot that's different than the one you have installed on your system? Is there a way to not allow load_policy to execute in a chroot?
I don't think we're going to be able to support generically using SELinux in chroots¹. Fundamentally chroot is a very weak virtualization mechanism; much of the core system leaks to the chroot (and vice versa), and that's the problem you're running into here. I think moving forward most of what people are doing with chroots (e.g. package building and especially testing) should be done with "real" virtualization like UML or Xen.
But one workaround for your problem may be to make SELinux appear to be disabled inside the chroot. I've attached two (completely untested) patches; the first attempts to make SELinux appear to be disabled if you don't mount /selinux inside the chroot, and the second makes load_policy exit immediately with 0 status if SELinux isn't enabled.
¹ By "generically" I mean e.g. a stock FC3 installation. Certainly it's possible to add policy for a specific chrooted application.
On Sun, 2005-01-09 at 12:48 -0500, Colin Walters wrote:
On Sat, 2005-01-08 at 21:55 -0800, Bob Kashani wrote:
When I install the selinux-policy-targeted rpm in a chroot it seems that load_policy is executed and loads the policy that's installed in the chroot into the running kernel (I'm assuming via %post). Should installing the selinux-policy-targeted rpm in a chroot allow this to happen? What if you're installing a policy into the chroot that's different than the one you have installed on your system? Is there a way to not allow load_policy to execute in a chroot?
I don't think we're going to be able to support generically using SELinux in chroots¹. Fundamentally chroot is a very weak virtualization mechanism; much of the core system leaks to the chroot (and vice versa), and that's the problem you're running into here. I think moving forward most of what people are doing with chroots (e.g. package building and especially testing) should be done with "real" virtualization like UML or Xen.
I'm actually playing around with UML as well. :) The only issue with virtualization is that you end up taking a performance hit but on the other hand it does make life easier.
But one workaround for your problem may be to make SELinux appear to be disabled inside the chroot. I've attached two (completely untested) patches; the first attempts to make SELinux appear to be disabled if you don't mount /selinux inside the chroot, and the second makes load_policy exit immediately with 0 status if SELinux isn't enabled.
I'll try your patches. But I did figure out a simple workaround. (not mounting /selinux in the chroot). It seems that if you don't mount /selinux in the chroot then load_policy doesn't try to install the policy in the chroot into the running kernel. I have no idea why that is the case. But everything seems to work without mounting /selinux so...in fact it seems that I don't even need /sys either. I just tried mounting only /proc (which is what I was doing in the first place) with selinux- policy-targeted-1.17.30-2.68 and everything works!!! :) I did do a 'touch /.autorelabel' as specified in the FAQ which seems to have helped with a few other things as well.
I'll let you know how it goes with your patches.
Thanks,
Bob
On Sun, 2005-01-09 at 19:51 -0800, Bob Kashani wrote:
I'm actually playing around with UML as well. :) The only issue with virtualization is that you end up taking a performance hit but on the other hand it does make life easier.
Right. By the way, I think Xen is in rawhide now, so that could be worth checking out.
I'll try your patches. But I did figure out a simple workaround. (not mounting /selinux in the chroot). It seems that if you don't mount /selinux in the chroot then load_policy doesn't try to install the policy in the chroot into the running kernel. I have no idea why that is the case.
Well, loading the policy will fail since load_policy just writes data to /selinux/load. I'm surprised that doesn't turn into a postinst error.
Anyways, I suspect that you don't want other tools inside the chroot to think SELinux is enabled, so the patches should help there. But I haven't tested this, so there may be something I'm missing.
But everything seems to work without mounting /selinux so...in fact it seems that I don't even need /sys either.
Lacking /sys will almost certainly cause problems.
I just tried mounting only /proc (which is what I was doing in the first place) with selinux- policy-targeted-1.17.30-2.68 and everything works!!! :) I did do a 'touch /.autorelabel' as specified in the FAQ which seems to have helped with a few other things as well.
What is it specifically that you are doing with the chroot? Building RPMs?
On Sun, 2005-01-09 at 23:20 -0500, Colin Walters wrote:
On Sun, 2005-01-09 at 19:51 -0800, Bob Kashani wrote:
I'm actually playing around with UML as well. :) The only issue with virtualization is that you end up taking a performance hit but on the other hand it does make life easier.
Right. By the way, I think Xen is in rawhide now, so that could be worth checking out.
Cool, I'll check it out. Thanks!!! :)
I'll try your patches. But I did figure out a simple workaround. (not mounting /selinux in the chroot). It seems that if you don't mount /selinux in the chroot then load_policy doesn't try to install the policy in the chroot into the running kernel. I have no idea why that is the case.
Well, loading the policy will fail since load_policy just writes data to /selinux/load. I'm surprised that doesn't turn into a postinst error.
I just checked the selinux-policy-targeted.spec and in the %post section at the very end there is an 'exit 0'.
Anyways, I suspect that you don't want other tools inside the chroot to think SELinux is enabled, so the patches should help there. But I haven't tested this, so there may be something I'm missing.
But everything seems to work without mounting /selinux so...in fact it seems that I don't even need /sys either.
Lacking /sys will almost certainly cause problems.
Really? Nothing fails to install because of it. I tried with and without it and there is no difference. But I'm only installing RPMS in the chroot at the moment so that might be the reason. I'll keep this in mind when I get around to building my RPMS later though...thanks. :)
I just tried mounting only /proc (which is what I was doing in the first place) with selinux- policy-targeted-1.17.30-2.68 and everything works!!! :) I did do a 'touch /.autorelabel' as specified in the FAQ which seems to have helped with a few other things as well.
What is it specifically that you are doing with the chroot? Building RPMs?
Yup.
Bob
On Sun, 2005-01-09 at 21:01 -0800, Bob Kashani wrote:
On Sun, 2005-01-09 at 23:20 -0500, Colin Walters wrote:
On Sun, 2005-01-09 at 19:51 -0800, Bob Kashani wrote:
I'm actually playing around with UML as well. :) The only issue with virtualization is that you end up taking a performance hit but on the other hand it does make life easier.
Right. By the way, I think Xen is in rawhide now, so that could be worth checking out.
Cool, I'll check it out. Thanks!!! :)
I'll try your patches. But I did figure out a simple workaround. (not mounting /selinux in the chroot). It seems that if you don't mount /selinux in the chroot then load_policy doesn't try to install the policy in the chroot into the running kernel. I have no idea why that is the case.
Well, loading the policy will fail since load_policy just writes data to /selinux/load. I'm surprised that doesn't turn into a postinst error.
I just checked the selinux-policy-targeted.spec and in the %post section at the very end there is an 'exit 0'.
Just to clarify: I meant that as an observation and not as something that would cause it to fail.
BTW: I have a selinux dir in my chroot but there is nothing in it. Where do the files in /selinux come from?
Bob
On Jan 10, 2005, Colin Walters walters@redhat.com wrote:
What is it specifically that you are doing with the chroot? Building RPMs?
In my case, what I used to do was to maintain two or more installs on each box, each of them up-to-date, such that, in case I messed up with the daily-use install (say rawhide), I could go back to a known-good install (say FC3 or even FC2).
Ever since SELinux came into the picture, it became impossible to do this properly.
What would be really nice would be if loading a policy into selinux affected the behavior within that chroot (or rather within the directory tree accessible from the root at the time of policy load), while leaving the policy for the original root alone. I suppose this would be tricky to implement, but I don't see that it would be impossible nor insecure. You might of course need some policy tweaks to enable a chroot dir to have a policy loaded inside it, that might override the part of the original-root policy that applied to the chroot, but nothing outside the chroot. Or something along these lines.
Personally, I'd find this useful, although now I see that, in order to keep a known-good alternate distro available, I'd better not be installing updates on it, since the updates might sometimes make it, erhm, ungood :-)
On Fri, 2005-01-14 at 20:13 -0200, Alexandre Oliva wrote:
On Jan 10, 2005, Colin Walters walters@redhat.com wrote:
What is it specifically that you are doing with the chroot? Building RPMs?
In my case, what I used to do was to maintain two or more installs on each box, each of them up-to-date, such that, in case I messed up with the daily-use install (say rawhide), I could go back to a known-good install (say FC3 or even FC2).
Xen.
On Jan 14, 2005, Colin Walters walters@redhat.com wrote:
On Fri, 2005-01-14 at 20:13 -0200, Alexandre Oliva wrote:
On Jan 10, 2005, Colin Walters walters@redhat.com wrote:
What is it specifically that you are doing with the chroot? Building RPMs?
In my case, what I used to do was to maintain two or more installs on each box, each of them up-to-date, such that, in case I messed up with the daily-use install (say rawhide), I could go back to a known-good install (say FC3 or even FC2).
Xen.
Not available in neither FC3 nor FC2 kernels. Nor earlier releases of FC, for that matter, where the significant kernel differences would make it even trickier.
Xen is the way forward. Keeping earlier installs is a way to go back. So Xen is not an option, as appealing as it might seem.
On Sun, 16 Jan 2005 16:20:32 -0200, Alexandre Oliva said:
On Jan 14, 2005, Colin Walters walters@redhat.com wrote:
Xen.
Not available in neither FC3 nor FC2 kernels.
It *is* however in the current FC-devel tree.
(I haven't actually tried it myself, as I'm usually running a custom kernel that resembles a -mm kernel with -execshield and Ingo's -RT patches on top...)
On Jan 16, 2005, Valdis.Kletnieks@vt.edu wrote:
On Sun, 16 Jan 2005 16:20:32 -0200, Alexandre Oliva said:
On Jan 14, 2005, Colin Walters walters@redhat.com wrote:
Xen.
Not available in neither FC3 nor FC2 kernels.
It *is* however in the current FC-devel tree.
Yeah, sure, but how does this help installing updates on my existing alternate FC1 or FC2 installs, without having to reboot FC3 or rawhide into them?
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
On Saturday 15 January 2005 09:13, Alexandre Oliva aoliva@redhat.com wrote:
In my case, what I used to do was to maintain two or more installs on each box, each of them up-to-date, such that, in case I messed up with the daily-use install (say rawhide), I could go back to a known-good install (say FC3 or even FC2).
The best thing to do would be to occasionally boot the older system to update it.
What would be really nice would be if loading a policy into selinux affected the behavior within that chroot (or rather within the directory tree accessible from the root at the time of policy load),
SE Linux controls all aspects of system security, including global thing such as mounting file systems and directly writing to block devices. If the chroot had a local policy as you suggest then which policy would control writing to the device node for the boot device?
Something like Xen is what you need. The below URL about Xen and hypervisor security may interest you.
http://sourceforge.net/mailarchive/forum.php?thread_id=6364737&forum_id=...
On Feb 19, 2005, Russell Coker russell@coker.com.au wrote:
SE Linux controls all aspects of system security, including global thing such as mounting file systems and directly writing to block devices. If the chroot had a local policy as you suggest then which policy would control writing to the device node for the boot device?
Err... No differently from the way the Xen solution you recommended would? Except, perhaps, for...
http://sourceforge.net/mailarchive/forum.php?thread_id=6364737&forum_id=...
which would require presumably yet another layer of MAC configuration files. Which means yet another level of setting up and overlapping settings, not really different from one possible implementation for chroot policies.
On Tuesday 22 February 2005 00:54, Alexandre Oliva aoliva@redhat.com wrote:
On Feb 19, 2005, Russell Coker russell@coker.com.au wrote:
SE Linux controls all aspects of system security, including global thing such as mounting file systems and directly writing to block devices. If the chroot had a local policy as you suggest then which policy would control writing to the device node for the boot device?
Err... No differently from the way the Xen solution you recommended would? Except, perhaps, for...
Xen is totally different to a chroot. Xen has a virtual environment which has it's own access controls. The URL below concerns methods of limiting interaction between Xen sessions (I don't know enough about Xen to comment on it).
With a chroot you might have /dev/hda1 mounted as the root file system, but inside the chroot the /dev/hda1 device node will still exist and grant access to the file system that's outside the chroot. I believe that Xen solves this problem but don't know the details.
http://sourceforge.net/mailarchive/forum.php?thread_id=6364737&forum_id=... 5600
which would require presumably yet another layer of MAC configuration files. Which means yet another level of setting up and overlapping settings, not really different from one possible implementation for chroot policies.
True, it could be considered to be slightly similar in concept to a well implemented chroot setup. But note that a Xen guest can't change the resources managed by the Xen host, and a similar level of isolation is required for a secure chroot.
Bob Kashani wrote:
When I install the selinux-policy-targeted rpm in a chroot it seems that load_policy is executed and loads the policy that's installed in the chroot into the running kernel (I'm assuming via %post). Should installing the selinux-policy-targeted rpm in a chroot allow this to happen? What if you're installing a policy into the chroot that's different than the one you have installed on your system? Is there a way to not allow load_policy to execute in a chroot?
Here is the AVC messages I'm getting:
Jan 8 21:38:23 chaucer kernel: audit(1105249103.605:0): avc: granted { load_policy } for pid=4233 exe=/usr/sbin/load_policy scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security Jan 8 21:38:23 chaucer kernel: security: 3 users, 4 roles, 316 types, 20 bools Jan 8 21:38:23 chaucer kernel: security: 53 classes, 7962 rules
Bob
rpm --noscripts
selinux@lists.fedoraproject.org
-
Alexandre Oliva -
Bob Kashani -
Colin Walters -
Daniel J Walsh -
Russell Coker -
Valdis.Kletnieks＠vt.edu