[OE-core] PSEUDO - SELinux support

Peter Seebach peter.seebach at windriver.com
Wed Jul 30 16:36:35 UTC 2014


On Mon, 28 Jul 2014 12:39:29 -0500
Mark Hatle <mark.hatle at 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.



More information about the Openembedded-core mailing list