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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
