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 04-16-2008, 11:45 PM
James Morris
 
Default Fedora buildsys and SELinux

On Wed, 16 Apr 2008, Karsten 'quaid' Wade wrote:

> As announced on fedora-devel-list[1], we'd like to come to a resolution
> (consensus, actions) on the challenges we have with SELinux in the
> Fedora build system.
>
> I expect the following:
>
> * All the parties are here now needed to figure this out
> * Someone better than me is going to reply with specifics about what is
> not working in the buildsys
> * We all agree it's pretty important to get this figured out in a good
> way

Can you please explain specifically what the problem is?


--
James Morris
<jmorris@namei.org>

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-17-2008, 12:14 AM
John Reiser
 
Default Fedora buildsys and SELinux

>> the challenges we have with SELinux in the Fedora build system.

> Can you please explain specifically what the problem is?

One of the problems is that the result of a pungi compose that is performed
with SELinux enforcing, does not install SELinux enabled by default,
because [a chain of events] the DVD/CD does not contain the policy file,
partly because under enforcing you cannot create a virtualized /dev/null
that has the right context.
http://bugzilla.redhat.com/show_bug.cgi?id=343861
http://bugzilla.redhat.com/show_bug.cgi?id=343851
The workaround is "setenforce 0" during the pungi compose.

In general, it looks to me like SELinux itself cannot be virtualized.
[I really didn't expect it, but nevertheless I cannot find it.]
This means that any time you want to "fake it", then you must
turn off enforcing, or create a full virtualized OS instance
that has enforcing off.

--

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-17-2008, 12:22 AM
Bill Nottingham
 
Default Fedora buildsys and SELinux

James Morris (jmorris@namei.org) said:
> > * All the parties are here now needed to figure this out
> > * Someone better than me is going to reply with specifics about what is
> > not working in the buildsys
> > * We all agree it's pretty important to get this figured out in a good
> > way
>
> Can you please explain specifically what the problem is?

You cannot create files in a chroot of a context not known by the
host policy. This means that if your host is running RHEL 5, you are
unable to compose any trees/images/livecds with SELinux enabled for
later releases.

Bill

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-17-2008, 12:43 AM
James Morris
 
Default Fedora buildsys and SELinux

On Wed, 16 Apr 2008, Bill Nottingham wrote:

> James Morris (jmorris@namei.org) said:
> > > * All the parties are here now needed to figure this out
> > > * Someone better than me is going to reply with specifics about what is
> > > not working in the buildsys
> > > * We all agree it's pretty important to get this figured out in a good
> > > way
> >
> > Can you please explain specifically what the problem is?
>
> You cannot create files in a chroot of a context not known by the
> host policy. This means that if your host is running RHEL 5, you are
> unable to compose any trees/images/livecds with SELinux enabled for
> later releases.

Ok, that's what I suspected.

One of the possible plans for this is to allow a process to run in a
separate policy namespace, and probably also utilize namespace support in
general.

This is non-trivial and needs more analysis.


- James
--
James Morris
<jmorris@namei.org>

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-17-2008, 02:24 AM
"Karsten 'quaid' Wade"
 
Default Fedora buildsys and SELinux

On Thu, 2008-04-17 at 10:43 +1000, James Morris wrote:
> On Wed, 16 Apr 2008, Bill Nottingham wrote:
>
> > James Morris (jmorris@namei.org) said:
> > > > * All the parties are here now needed to figure this out
> > > > * Someone better than me is going to reply with specifics about what is
> > > > not working in the buildsys
> > > > * We all agree it's pretty important to get this figured out in a good
> > > > way
> > >
> > > Can you please explain specifically what the problem is?
> >
> > You cannot create files in a chroot of a context not known by the
> > host policy. This means that if your host is running RHEL 5, you are
> > unable to compose any trees/images/livecds with SELinux enabled for
> > later releases.
>
> Ok, that's what I suspected.
>
> One of the possible plans for this is to allow a process to run in a
> separate policy namespace, and probably also utilize namespace support in
> general.
>
> This is non-trivial and needs more analysis.

Thanks. When we get to the point of needing to justify resource
allocation on the Red Hat side, I'm here to present the "Fedora
leadership request", if needed. Otherwise, not sure if this is going to
be important enough to the intersecting sets of Fedoran and SELinux
hacker who are not part of the @redhat.com set.

- Karsten
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-17-2008, 03:23 AM
Bill Nottingham
 
Default Fedora buildsys and SELinux

James Morris (jmorris@namei.org) said:
> > You cannot create files in a chroot of a context not known by the
> > host policy. This means that if your host is running RHEL 5, you are
> > unable to compose any trees/images/livecds with SELinux enabled for
> > later releases.
>
> Ok, that's what I suspected.
>
> One of the possible plans for this is to allow a process to run in a
> separate policy namespace, and probably also utilize namespace support in
> general.
>
> This is non-trivial and needs more analysis.

Incidentally, this is also one of the blockers for policy-in-packages,
rather than a monolithic one.

Bill

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-17-2008, 01:12 PM
Stephen Smalley
 
Default Fedora buildsys and SELinux

On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> James Morris (jmorris@namei.org) said:
> > > You cannot create files in a chroot of a context not known by the
> > > host policy. This means that if your host is running RHEL 5, you are
> > > unable to compose any trees/images/livecds with SELinux enabled for
> > > later releases.
> >
> > Ok, that's what I suspected.
> >
> > One of the possible plans for this is to allow a process to run in a
> > separate policy namespace, and probably also utilize namespace support in
> > general.
> >
> > This is non-trivial and needs more analysis.
>
> Incidentally, this is also one of the blockers for policy-in-packages,
> rather than a monolithic one.

I assume you mean setting down unknown file labels rather than
per-namespace or per-chroot policy support. I think they are related
but different. The former is required if you always plan to install the
files _before_ loading the policy. The latter is required primarily for
getting any scriptlets to run in the right security contexts so that any
files they create are labeled appropriately within the chroot.

Also, I wanted to emphasize that chroot is different than unsharing the
filesystem namespace, and per-chroot policy is not the same thing as
per-namespace policy. I'd expect though that it would actually be a
per-process policy mechanism, with most processes sharing the same
policy but programs like rpm being able to unshare policy from their
parent and then load a private policy to be applied only to their
descendants.

--
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 04-22-2008, 02:02 PM
Daniel J Walsh
 
Default Fedora buildsys and SELinux

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Nottingham wrote:
> James Morris (jmorris@namei.org) said:
>>> * All the parties are here now needed to figure this out
>>> * Someone better than me is going to reply with specifics about what is
>>> not working in the buildsys
>>> * We all agree it's pretty important to get this figured out in a good
>>> way
>> Can you please explain specifically what the problem is?
>
> You cannot create files in a chroot of a context not known by the
> host policy. This means that if your host is running RHEL 5, you are
> unable to compose any trees/images/livecds with SELinux enabled for
> later releases.
>
> Bill
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Just catching up on this email chain.

The far more insidious problem is the act of loading policy in the
chroot effects the kernel of the host. So processes that are running in
the host become invalidated when the client loads a policy. This
happens even in the case where you are building a chroot environment on
the SAME os. Since the spec file is running semanage commands to modify
and add unconfined_t users, the unconfined processes of the parent and
potential labels become unknown to the kernel for a period of time,
which ends up labeling the files and processes as unlabeled_t. When
this happens files labeled unlabeled_t can not be accesses by confined
process and if a process becomes unlabeled_t it will not be allowed any
access on the box, which can cause the process to crash or go into in
infinite loop. If I build a livedvd, I end

setenforce 0
livedvd ...
load_policy
setenforce 1
And sometimes I still need to
fixfiles restore
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgN7/wACgkQrlYvE4MpobNzEgCgysNQd6+WuH9GrSSTJy2YZuwd
cNwAn2ioJTeBG416OT+CITaKwoAjWsC9
=/F7+
-----END PGP SIGNATURE-----

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-22-2008, 02:58 PM
Tomas Mraz
 
Default Fedora buildsys and SELinux

> Bill Nottingham wrote:
> > James Morris (jmorris@namei.org) said:
> >>> * All the parties are here now needed to figure this out
> >>> * Someone better than me is going to reply with specifics about what is
> >>> not working in the buildsys
> >>> * We all agree it's pretty important to get this figured out in a good
> >>> way
> >> Can you please explain specifically what the problem is?
> >
> > You cannot create files in a chroot of a context not known by the
> > host policy. This means that if your host is running RHEL 5, you are
> > unable to compose any trees/images/livecds with SELinux enabled for
> > later releases.
> >
> > Bill
> >
> > --
> > fedora-selinux-list mailing list
> > fedora-selinux-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> Just catching up on this email chain.
>
> The far more insidious problem is the act of loading policy in the
> chroot effects the kernel of the host. So processes that are running in
> the host become invalidated when the client loads a policy. This
> happens even in the case where you are building a chroot environment on
> the SAME os. Since the spec file is running semanage commands to modify
> and add unconfined_t users, the unconfined processes of the parent and
> potential labels become unknown to the kernel for a period of time,
> which ends up labeling the files and processes as unlabeled_t. When
> this happens files labeled unlabeled_t can not be accesses by confined
> process and if a process becomes unlabeled_t it will not be allowed any
> access on the box, which can cause the process to crash or go into in
> infinite loop. If I build a livedvd, I end
>
> setenforce 0
> livedvd ...
> load_policy
> setenforce 1
> And sometimes I still need to
> fixfiles restore

Could it be solved by kernel preventing loading the policy when the
process which tries that is in the chroot? It seems to me that it
doesn't make any sense to allow that. Then with enabling creating files
with a context unknown to the policy the machine could run in enforcing
mode although the process which does the compose would of course have to
be unconfined.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-22-2008, 03:11 PM
Eric Paris
 
Default Fedora buildsys and SELinux

On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
> > Bill Nottingham wrote:
> > > James Morris (jmorris@namei.org) said:
> > >>> * All the parties are here now needed to figure this out
> > >>> * Someone better than me is going to reply with specifics about what is
> > >>> not working in the buildsys
> > >>> * We all agree it's pretty important to get this figured out in a good
> > >>> way
> > >> Can you please explain specifically what the problem is?
> > >
> > > You cannot create files in a chroot of a context not known by the
> > > host policy. This means that if your host is running RHEL 5, you are
> > > unable to compose any trees/images/livecds with SELinux enabled for
> > > later releases.
> > >
> > > Bill
> > >
> > > --
> > > fedora-selinux-list mailing list
> > > fedora-selinux-list@redhat.com
> > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> > Just catching up on this email chain.
> >
> > The far more insidious problem is the act of loading policy in the
> > chroot effects the kernel of the host. So processes that are running in
> > the host become invalidated when the client loads a policy. This
> > happens even in the case where you are building a chroot environment on
> > the SAME os. Since the spec file is running semanage commands to modify
> > and add unconfined_t users, the unconfined processes of the parent and
> > potential labels become unknown to the kernel for a period of time,
> > which ends up labeling the files and processes as unlabeled_t. When
> > this happens files labeled unlabeled_t can not be accesses by confined
> > process and if a process becomes unlabeled_t it will not be allowed any
> > access on the box, which can cause the process to crash or go into in
> > infinite loop. If I build a livedvd, I end
> >
> > setenforce 0
> > livedvd ...
> > load_policy
> > setenforce 1
> > And sometimes I still need to
> > fixfiles restore
>
> Could it be solved by kernel preventing loading the policy when the
> process which tries that is in the chroot? It seems to me that it
> doesn't make any sense to allow that. Then with enabling creating files
> with a context unknown to the policy the machine could run in enforcing
> mode although the process which does the compose would of course have to
> be unconfined.

How about changes to selinuxfs?

mount selinuxfs /chroot/selinux -t selinuxfs -o ro

if we are mounted with ro we make everything inside ro so the process
inside the chroot using the chroot version of selinuxfs couldn't screw
the system.

Still doesn't allow laying down invalid types on disk, is that a problem
today? Although I didn't like the rpm demands for illegal types this
seems like a case where we might want to take that patch...

-Eric

--
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 06:54 AM.

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