Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[David Howells <dhowells@redhat.com>]

Stephen Smalley <sds@tycho.nsa.gov> wrote:

> All your code has to do is invoke a function provided by libselinux.

Calling libselinux means it's a special case for a specific LSM.

I think the best way to do this, then, has to be to dlopen the appropriate LSM
library.  That way I don't need to do any conditional compilation or linking,
but can build all the bits in to cachefilesd and have the appropriate one
selected by the /etc/cachefilesd.conf.

So, what do I invoke in libselinux, how do I configure it, and how do I
integrate the config into my RPM and install it?

And then what does it give me that I can hand to the kernel (a context string
for SELinux, I presume), how do I get the kernel to make a check on it, how do
I configure the check and how do I install that config from my RPM (I presume
I just need to modify the .fc, .if and .te files that I have already)?

> That mostly works, but it means that an update to policy may require an
> update to /etc/cachefilesd.conf, or that switching from one policy to
> another might likewise require changing that file.  Versus using a
> separate policy-provided config file for the label.

Whilst that's a fair point, if it's in a config file somewhere, then someone
may want to change it or someone may want to provide a second file for a
second cache with a different security label.

> BTW, as should be obvious, some LSMs aren't label-based at all, so it
> would need to be optional.

Aargh.  In which case it might not be possible to make the SELinux context
passing from userspace -> kernel generic for all LSMs:-(

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/