FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 05-20-2008, 07:33 PM
Stephen Smalley
 
Default selinux + livecd-creator, May 20, 2008

On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
> ***passwd:
> running a system with selinux enforcing/permissive (doesn't matter) and
> attempting to run livecd-creator with selinux --disabled results in
> passwd espoloding. passwd called is_selinux_enabled() which says yes
> since /proc/mounts has an selinuxfs and the passwd calls
> selinux_enforcing() which explodes when it can't find
> a /selinux/enforce. First discussion was to change /proc/mounts to hide
> the selinuxfs, sounds like a good plan until I realize /proc/mounts is
> actually link to /proc/self/mounts and that its getting way to complex
> tying to set up FS namespaces or whatever this is going to take. Right
> now I'm thinking of creating a /selinux with enforce=0 in all cases
> inside the chroot, anyone see a problem with that? (I could also work
> on fixing passwd, but i'm trying to be as 'backwards compatible' as
> possible....

Wait - you are confusing /proc/mounts and /proc/filesystems.
IIUC, you are not mounting selinuxfs within the chroot and thus it does
not appear in /proc/mounts regardless. But it does appear
in /proc/filesystems, and that is why is_selinux_enabled() returns 1.
If you bind mount a fake file over /proc/filesystems that excludes
selinuxfs, it should cause is_selinux_enabled() to return 0.

> ***restorecon:
> do we have an interface to see what is actually in security.xattr?

No - because we don't have separate interfaces for getting/setting MAC
labels vs. getting/setting xattrs, unlike FreeBSD (where MAC labels are
a first class construct and xattrs are just a storage mechanism that may
or may not be used by the MAC module).

We had talked about the possibility of allowing processes with
CAP_MAC_ADMIN to get the raw context via getxattr in the deferred
contexts thread on selinux list. But see my comments there.

> Making use of the wonderful new deferred selinux context patch set from
> the kernel I get beautiful message like:
>
> /sbin/restorecon reset /sbin/dump context
> system_ubject_r:unlabeled_t:s0->system_ubject_r:eparis_exec_t:s0
>
> The file wasn't really "unlabeled_t" it just wasn't a valid label on the
> host machine. Since restorecon/fixfiles runs over the same files like 3
> times during a livecd creation this gets rather annoying. Do we have an
> interface I could use to make restorecon do the right comparison here?

Well, could we instead avoid running restorecon/fixfiles multiple times
on the same files? And ideally just get rpm to label the files
correctly in the first place since that is why we added the kernel
patch?

> ***allow unlabeled_t fs_t:filesystem associate:
> anyone have thoughts on how we want to handle this?

I identified this in the deferred contexts patch description as needing
to be allowed, along with a policy module to do it. See that.

> I can probably do
> some sort of fscontext= mount magic once i figure out the right fs we
> are talking about and where the script does the mount. But then host
> policy is going to need rules to allow everything that can associate
> with fs_t with fs_allow_unlabeled_t. Is that hard? I assume Dan can
> help me out there. Does this sound like a good way to solve it? Is
> hard coding some 'fscontext=' line into livecd-creator a good idea?
> Should I just generically allow it? Should I make livecd-creator load a
> policy module to start off and unload it at the end? (I don't like
> this idea since I've learned livecd-creator can be pretty fragile and
> leave things half done/half undone...)

I would tend to just allow it, either in the base policy or in a policy
module used only for livecd-creator, possibly installed from its package
if you don't want to load/remove it on each use.

> ***Invalid prefix *
> On rawhide we just dropped that stuff altogether. Can we do the same on
> F8? Is it actually causing a problem? Dan, any hints on how I can make
> the system lie to you?

Do you mean just remove the security_check_context() call from
seobject.py? Yes, I think you can just drop it.

> Needless to say, I successfully built an F8 livecd with types not known
> tot he host system on rawhide today, booted, and logged in.

That sounds favorable.

Now you just need to travel back in time before RHEL 5 was released, add
the necessary support to it, and kill the person who will stop Skynet.

> tomorrow I spend more time typing to make the policy for livecd-creator
> a bit better.....

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:35 PM
Jeremy Katz
 
Default selinux + livecd-creator, May 20, 2008

On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
> ***passwd:
> running a system with selinux enforcing/permissive (doesn't matter) and
> attempting to run livecd-creator with selinux --disabled results in
> passwd espoloding. passwd called is_selinux_enabled() which says yes
> since /proc/mounts has an selinuxfs and the passwd calls
> selinux_enforcing() which explodes when it can't find
> a /selinux/enforce. First discussion was to change /proc/mounts to hide
> the selinuxfs, sounds like a good plan until I realize /proc/mounts is
> actually link to /proc/self/mounts and that its getting way to complex
> tying to set up FS namespaces or whatever this is going to take. Right
> now I'm thinking of creating a /selinux with enforce=0 in all cases
> inside the chroot, anyone see a problem with that? (I could also work
> on fixing passwd, but i'm trying to be as 'backwards compatible' as
> possible....

That seems pretty reasonable to me. The contortions of trying to
get /proc/mounts right are definitely not worth it

> ***restorecon:
> do we have an interface to see what is actually in security.xattr?
> Making use of the wonderful new deferred selinux context patch set from
> the kernel I get beautiful message like:
> The file wasn't really "unlabeled_t" it just wasn't a valid label on the
> host machine. Since restorecon/fixfiles runs over the same files like 3
> times during a livecd creation this gets rather annoying. Do we have an
> interface I could use to make restorecon do the right comparison here?

If not, we could dump the output to /dev/null ;-) But, that seems a bit
less than the ideal of really checking

> ***allow unlabeled_t fs_t:filesystem associate:
> anyone have thoughts on how we want to handle this? I can probably do
> some sort of fscontext= mount magic once i figure out the right fs we
> are talking about and where the script does the mount. But then host
> policy is going to need rules to allow everything that can associate
> with fs_t with fs_allow_unlabeled_t.

So I'm not clear on exactly what the cause of this is or even what it's
trying to say.

> Needless to say, I successfully built an F8 livecd with types not known
> tot he host system on rawhide today, booted, and logged in.

Awesome!

Jeremy

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:37 PM
Jeremy Katz
 
Default selinux + livecd-creator, May 20, 2008

On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
> > Making use of the wonderful new deferred selinux context patch set from
> > the kernel I get beautiful message like:
> >
> > /sbin/restorecon reset /sbin/dump context
> > system_ubject_r:unlabeled_t:s0->system_ubject_r:eparis_exec_t:s0
> >
> > The file wasn't really "unlabeled_t" it just wasn't a valid label on the
> > host machine. Since restorecon/fixfiles runs over the same files like 3
> > times during a livecd creation this gets rather annoying. Do we have an
> > interface I could use to make restorecon do the right comparison here?
>
> Well, could we instead avoid running restorecon/fixfiles multiple times
> on the same files? And ideally just get rpm to label the files
> correctly in the first place since that is why we added the kernel
> patch?

FWIW, we do a final pass with restorecon/fixfiles at the end of creating
the files just so that we can ensure that any files that were created as
the result of a %post script or anything else which doesn't transition
correctly (... perhaps because the policy doesn't know it needs to) ends
up with the right final label. This is pretty confined to just the
livecd-creator case, though.

Jeremy

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:43 PM
Daniel J Walsh
 
Default selinux + livecd-creator, May 20, 2008

Jeremy Katz wrote:
> On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
>> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
>>> Making use of the wonderful new deferred selinux context patch set from
>>> the kernel I get beautiful message like:
>>>
>>> /sbin/restorecon reset /sbin/dump context
>>> system_ubject_r:unlabeled_t:s0->system_ubject_r:eparis_exec_t:s0
>>>
>>> The file wasn't really "unlabeled_t" it just wasn't a valid label on the
>>> host machine. Since restorecon/fixfiles runs over the same files like 3
>>> times during a livecd creation this gets rather annoying. Do we have an
>>> interface I could use to make restorecon do the right comparison here?
>> Well, could we instead avoid running restorecon/fixfiles multiple times
>> on the same files? And ideally just get rpm to label the files
>> correctly in the first place since that is why we added the kernel
>> patch?
>
> FWIW, we do a final pass with restorecon/fixfiles at the end of creating
> the files just so that we can ensure that any files that were created as
> the result of a %post script or anything else which doesn't transition
> correctly (... perhaps because the policy doesn't know it needs to) ends
> up with the right final label. This is pretty confined to just the
> livecd-creator case, though.
>
> Jeremy
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Can we use fixfiles restore instead of restorecon. It will output a
little "*" for every 10,000 files it relabels and we don't need to see
thousands of useless restorecon lines.


--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:43 PM
Jeremy Katz
 
Default selinux + livecd-creator, May 20, 2008

On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
> Can we use fixfiles restore instead of restorecon. It will output a
> little "*" for every 10,000 files it relabels and we don't need to see
> thousands of useless restorecon lines.

Sure -- I can even conditionalize it being restorecon vs fixfiles based
on whether you've asked for verbose output or not

Jeremy

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:43 PM
Daniel J Walsh
 
Default selinux + livecd-creator, May 20, 2008

Eric Paris wrote:
> ***passwd:
> running a system with selinux enforcing/permissive (doesn't matter) and
> attempting to run livecd-creator with selinux --disabled results in
> passwd espoloding. passwd called is_selinux_enabled() which says yes
> since /proc/mounts has an selinuxfs and the passwd calls
> selinux_enforcing() which explodes when it can't find
> a /selinux/enforce. First discussion was to change /proc/mounts to hide
> the selinuxfs, sounds like a good plan until I realize /proc/mounts is
> actually link to /proc/self/mounts and that its getting way to complex
> tying to set up FS namespaces or whatever this is going to take. Right
> now I'm thinking of creating a /selinux with enforce=0 in all cases
> inside the chroot, anyone see a problem with that? (I could also work
> on fixing passwd, but i'm trying to be as 'backwards compatible' as
> possible....
>
> ***restorecon:
> do we have an interface to see what is actually in security.xattr?
> Making use of the wonderful new deferred selinux context patch set from
> the kernel I get beautiful message like:
>
> /sbin/restorecon reset /sbin/dump context
> system_ubject_r:unlabeled_t:s0->system_ubject_r:eparis_exec_t:s0
>
> The file wasn't really "unlabeled_t" it just wasn't a valid label on the
> host machine. Since restorecon/fixfiles runs over the same files like 3
> times during a livecd creation this gets rather annoying. Do we have an
> interface I could use to make restorecon do the right comparison here?
>
> ***allow unlabeled_t fs_t:filesystem associate:
> anyone have thoughts on how we want to handle this? I can probably do
> some sort of fscontext= mount magic once i figure out the right fs we
> are talking about and where the script does the mount. But then host
> policy is going to need rules to allow everything that can associate
> with fs_t with fs_allow_unlabeled_t. Is that hard? I assume Dan can
> help me out there. Does this sound like a good way to solve it? Is
> hard coding some 'fscontext=' line into livecd-creator a good idea?
> Should I just generically allow it? Should I make livecd-creator load a
> policy module to start off and unload it at the end? (I don't like
> this idea since I've learned livecd-creator can be pretty fragile and
> leave things half done/half undone...)
>
> ***Invalid prefix *
> On rawhide we just dropped that stuff altogether. Can we do the same on
> F8? Is it actually causing a problem? Dan, any hints on how I can make
> the system lie to you?
Can't you just mount /dev/null on /selinux/context to get this to always
succeed?
>
> Needless to say, I successfully built an F8 livecd with types not known
> tot he host system on rawhide today, booted, and logged in.
>
> tomorrow I spend more time typing to make the policy for livecd-creator
> a bit better.....
>
> -Eric
>

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:46 PM
Stephen Smalley
 
Default selinux + livecd-creator, May 20, 2008

On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
> Jeremy Katz wrote:
> > On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
> >> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
> >>> Making use of the wonderful new deferred selinux context patch set from
> >>> the kernel I get beautiful message like:
> >>>
> >>> /sbin/restorecon reset /sbin/dump context
> >>> system_ubject_r:unlabeled_t:s0->system_ubject_r:eparis_exec_t:s0
> >>>
> >>> The file wasn't really "unlabeled_t" it just wasn't a valid label on the
> >>> host machine. Since restorecon/fixfiles runs over the same files like 3
> >>> times during a livecd creation this gets rather annoying. Do we have an
> >>> interface I could use to make restorecon do the right comparison here?
> >> Well, could we instead avoid running restorecon/fixfiles multiple times
> >> on the same files? And ideally just get rpm to label the files
> >> correctly in the first place since that is why we added the kernel
> >> patch?
> >
> > FWIW, we do a final pass with restorecon/fixfiles at the end of creating
> > the files just so that we can ensure that any files that were created as
> > the result of a %post script or anything else which doesn't transition
> > correctly (... perhaps because the policy doesn't know it needs to) ends
> > up with the right final label. This is pretty confined to just the
> > livecd-creator case, though.
> >
> > Jeremy
> >
> > --
> > fedora-selinux-list mailing list
> > fedora-selinux-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> Can we use fixfiles restore instead of restorecon. It will output a
> little "*" for every 10,000 files it relabels and we don't need to see
> thousands of useless restorecon lines.

Isn't that just the same as calling restorecon with -p rather than -v?

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:52 PM
Stephen Smalley
 
Default selinux + livecd-creator, May 20, 2008

On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
> > ***restorecon:
> > do we have an interface to see what is actually in security.xattr?
>
> No - because we don't have separate interfaces for getting/setting MAC
> labels vs. getting/setting xattrs, unlike FreeBSD (where MAC labels are
> a first class construct and xattrs are just a storage mechanism that may
> or may not be used by the MAC module).
>
> We had talked about the possibility of allowing processes with
> CAP_MAC_ADMIN to get the raw context via getxattr in the deferred
> contexts thread on selinux list. But see my comments there.

In particular, see:
http://marc.info/?l=selinux&m=121016477203440&w=2
http://marc.info/?l=selinux&m=121016814610025&w=2
http://marc.info/?l=selinux&m=121017332919586&w=2

It is possible, but we have to figure out how we want to handle it; we
don't want every getxattr call to trigger a full capable() check along
with auditing.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:54 PM
Stephen Smalley
 
Default selinux + livecd-creator, May 20, 2008

On Tue, 2008-05-20 at 15:43 -0400, Jeremy Katz wrote:
> On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
> > Can we use fixfiles restore instead of restorecon. It will output a
> > little "*" for every 10,000 files it relabels and we don't need to see
> > thousands of useless restorecon lines.
>
> Sure -- I can even conditionalize it being restorecon vs fixfiles based
> on whether you've asked for verbose output or not

I think all you need to do is omit the -v from restorecon if they didn't
ask for verbose output (or use -p instead if you want some indication of
progress). fixfiles is just a wrapper script around setfiles and
restorecon with some additional functionality, but in this case I'm not
sure it adds anything.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-20-2008, 07:56 PM
Stephen Smalley
 
Default selinux + livecd-creator, May 20, 2008

On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
> Eric Paris wrote:
> > ***passwd:
> > running a system with selinux enforcing/permissive (doesn't matter) and
> > attempting to run livecd-creator with selinux --disabled results in
> > passwd espoloding. passwd called is_selinux_enabled() which says yes
> > since /proc/mounts has an selinuxfs and the passwd calls
> > selinux_enforcing() which explodes when it can't find
> > a /selinux/enforce. First discussion was to change /proc/mounts to hide
> > the selinuxfs, sounds like a good plan until I realize /proc/mounts is
> > actually link to /proc/self/mounts and that its getting way to complex
> > tying to set up FS namespaces or whatever this is going to take. Right
> > now I'm thinking of creating a /selinux with enforce=0 in all cases
> > inside the chroot, anyone see a problem with that? (I could also work
> > on fixing passwd, but i'm trying to be as 'backwards compatible' as
> > possible....
> >
> > ***restorecon:
> > do we have an interface to see what is actually in security.xattr?
> > Making use of the wonderful new deferred selinux context patch set from
> > the kernel I get beautiful message like:
> >
> > /sbin/restorecon reset /sbin/dump context
> > system_ubject_r:unlabeled_t:s0->system_ubject_r:eparis_exec_t:s0
> >
> > The file wasn't really "unlabeled_t" it just wasn't a valid label on the
> > host machine. Since restorecon/fixfiles runs over the same files like 3
> > times during a livecd creation this gets rather annoying. Do we have an
> > interface I could use to make restorecon do the right comparison here?
> >
> > ***allow unlabeled_t fs_t:filesystem associate:
> > anyone have thoughts on how we want to handle this? I can probably do
> > some sort of fscontext= mount magic once i figure out the right fs we
> > are talking about and where the script does the mount. But then host
> > policy is going to need rules to allow everything that can associate
> > with fs_t with fs_allow_unlabeled_t. Is that hard? I assume Dan can
> > help me out there. Does this sound like a good way to solve it? Is
> > hard coding some 'fscontext=' line into livecd-creator a good idea?
> > Should I just generically allow it? Should I make livecd-creator load a
> > policy module to start off and unload it at the end? (I don't like
> > this idea since I've learned livecd-creator can be pretty fragile and
> > leave things half done/half undone...)
> >
> > ***Invalid prefix *
> > On rawhide we just dropped that stuff altogether. Can we do the same on
> > F8? Is it actually causing a problem? Dan, any hints on how I can make
> > the system lie to you?
> Can't you just mount /dev/null on /selinux/context to get this to always
> succeed?

I don't believe so, no. Remember that /selinux/context is a
transaction-based interface where the caller writes the context and then
reads back the canonicalized context. Omitting /selinux/context
altogether makes matchpathcon() happy, but not explicit
security_check_context() calls unless they also choose to ignore ENOENT.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 

Thread Tools




All times are GMT. The time now is 09:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org