SELinux support

SELinux support

[Enrico Scholz]

[ https://bugzilla.yoctoproject.org/show_bug.cgi?id=6580 ]

Hi,

after upgrade to recent pseudo 1.6+, oe-core stops to build as a
confined SELinux now.  This happens because SELinux provides more
than the xattr file api and 'pseudo' does not intercept e.g. writing
into '/proc/self/attr/fscreate'.

IMO, turning off every SELinux related operation in do_install() (which
is wrapped by 'pseudo') is a clean way to fix and improve building.  If
OE supports SELinux for targets sometime, the file relabeling should be
done in do_rootfs() by using a chroot aware 'restorecon' (e.g. which
reads the file context policy from the chroot but not from system wide
/etc/selinux).

Unfortunately, I do not know a way to make applications think they are
running without SELinux.  But patching 'pseudo' to return faked values
for 'is_selinux_enabled()' seems to be a good solution.

Bug #6580 mentioned at the beginning contains some discussion and a
patch.  What do other people think about it?



Enrico

Re: PSEUDO - SELinux support

[Mark Hatle]

On 7/28/14, 12:01 PM, Enrico Scholz wrote:
> [ https://bugzilla.yoctoproject.org/show_bug.cgi?id=6580 ]
>
> Hi,
>
> after upgrade to recent pseudo 1.6+, oe-core stops to build as a
> confined SELinux now.  This happens because SELinux provides more
> than the xattr file api and 'pseudo' does not intercept e.g. writing
> into '/proc/self/attr/fscreate'.

The issue is that there are two ways to set the selinux values.  One is via 
xattr, which we do capture in pseudo -- specifically to allow components to set 
xattrs [including security attributes].  The other is via some random proc file 
entry.  This was previously unknown to me.  There is a slight chance we can 
attempt to capture access to that file as well and act on it within the pseudo 
context.  (This may be more difficult though.)

> IMO, turning off every SELinux related operation in do_install() (which
> is wrapped by 'pseudo') is a clean way to fix and improve building.  If
> OE supports SELinux for targets sometime, the file relabeling should be
> done in do_rootfs() by using a chroot aware 'restorecon' (e.g. which
> reads the file context policy from the chroot but not from system wide
> /etc/selinux).

My feeling is that the security contexts set when pseudo is running should never 
make it to the 'real' filesystem, and should only be stored internally.

If we have programs that are setting security contexts on the system, as a 
host-tool -- this will end up being host-contamination as well.

As for the restorecon, there are otherways of setting security contexts as well. 
  Look at the 'Tizen' smack stuff as an example.  During the package installs 
they run through a series of rpm(4) plugins that evaluate what was installed and 
assign an appropriate security context.  While these are not selinux contexts, 
the interface is similar.

> Unfortunately, I do not know a way to make applications think they are
> running without SELinux.  But patching 'pseudo' to return faked values
> for 'is_selinux_enabled()' seems to be a good solution.

This could work, but I think it's only part of the solution.  We need to tell 
applications to stop spewing contexts that have nothing to do with the (virtual) 
filesystem we're working with.  We also need to get a reasonable way to make 
sure pseudo is capturing all of the contexts it can.

My other concern with the is_selinux_enabled is that it's not an API within the 
libc functions.  So would defining this cause any issues?  I'm not sure either way.

At a minimum, telling a pseudo running session that selinux is not enabled (at 
the host level) is probably the correct behavior.

Intercepting xattr is needed, and potentially access to the special proc files 
may also be needed... [once we intercept though, what do we do with the data?]

> Bug #6580 mentioned at the beginning contains some discussion and a
> patch.  What do other people think about it?

We definitely need input on this for people's use cases so that we can come up 
with a reasonable solution.

As mentioned in the bug, pseudo was not originally designed to work in any type 
of selinux enforcing mode.  If it happened to work, great -- but we didn't do 
any engineering there.  We knew that some levels of selinux support and grsec 
support would cause pseudo to not be able to LD_PRELOAD, which would fail.

The recommendation has always been to put your build machines behind a firewall, 
and put selinux into permissive mode (or disable it).  But if we can try to make 
the level of accidental functionality continue to work, I'm all for it.

--Mark

Re: PSEUDO - SELinux support

[Peter Seebach]

On Mon, 28 Jul 2014 12:39:29 -0500
Mark Hatle <mark.hatle@windriver.com> wrote:

> Intercepting xattr is needed, and potentially access to the special proc files 
> may also be needed... [once we intercept though, what do we do with the data?]

This is pretty much where the problem comes in. The reason for the xattr
support is to make it mechanically possible to create things which would have
extended attributes such as security.selinux values. But if we are picking up
such values from the host, and they make it into our rootfs, that's host
contamination.

For modes, we can do a decent job of making things work by just setting
reasonably plausible inferred modes which won't cause problems in the
underlying filesystem, and storing the target rootfs modes in the database.

For xattrs, I don't think we can do that, really. The problem is that there's
no generic way to tell whether a given proposed selinux attribute is coming
from logic relating to the target filesystem, or from the host's filesystem.

If we hypothetically intercepted proc/self/attr/fscreate writes, that might
help some. I was originally concerned about it being written outside the
pseudo environment, but it occurs to me that if it were, that would also
imply that whatever value was written probably got derived from things that
were read outside the pseudo environment, so basically we'd be rendering
unto SELinux that which is SELinux's, and it wouldn't affect our rootfs
choices either way. I think.

I am not at all sure whether we can patch is_selinux_enabled(). I also don't
know that this would work for the other use cases, because some things that
want xattr support may not try to write selinux attributes if that returns
false, but we might want them to write those attributes.

I will say that, in general, running in an actual selinux environment is
probably going to break sometimes, because pseudo depends on doing things
that should absolutely be prohibited in any sort of secure environment. The
entire concept behind things like fakeroot and pseudo is to create a runtime
environment which is broken in a useful way.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.