11:55 p.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
12:20 a.m.
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'?
9:33 p.m.
On Sun, 2005-01-09 at 01:20 -0500, Valdis.Kletnieks(a)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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
11:48 a.m.
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.
9:51 p.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
10:20 p.m.
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?
11:01 p.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
12:01 a.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
4:13 p.m.
On Jan 10, 2005, Colin Walters <walters(a)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 :-)
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
6:32 p.m.
On Fri, 2005-01-14 at 20:13 -0200, Alexandre Oliva wrote:
On Jan 10, 2005, Colin Walters <walters(a)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.
12:20 p.m.
On Jan 14, 2005, Colin Walters <walters(a)redhat.com> wrote:
On Fri, 2005-01-14 at 20:13 -0200, Alexandre Oliva wrote:
> On Jan 10, 2005, Colin Walters <walters(a)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.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
6:09 p.m.
On Sun, 16 Jan 2005 16:20:32 -0200, Alexandre Oliva said:
On Jan 14, 2005, Colin Walters <walters(a)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...)
10:17 a.m.
On Jan 16, 2005, Valdis.Kletnieks(a)vt.edu wrote:
On Sun, 16 Jan 2005 16:20:32 -0200, Alexandre Oliva said:
> On Jan 14, 2005, Colin Walters <walters(a)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(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
6:43 a.m.
On Saturday 15 January 2005 09:13, Alexandre Oliva <aoliva(a)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_...
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7:54 a.m.
On Feb 19, 2005, Russell Coker <russell(a)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...
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.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
8:33 a.m.
On Tuesday 22 February 2005 00:54, Alexandre Oliva <aoliva(a)redhat.com> wrote:
On Feb 19, 2005, Russell Coker <russell(a)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_...
>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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
9:24 a.m.
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
6997
days inactive
7040
days old
selinux@lists.fedoraproject.org
17 comments
6 participants
participants (6)
-
Alexandre Oliva -
Bob Kashani -
Colin Walters -
Daniel J Walsh -
Russell Coker -
Valdis.Kletnieks＠vt.edu