So, basically, userspace programs (outside of security tools) aren't supposed
to need access to the security infrastructure?
It is if I have to maintain a special pieces of code for each possible LSM.
One piece for SELinux, one piece for AppArmour, one piece for Smack, one piece
for Casey's security system. That sounds like a pain.
In /usr/bin ldd reports approximately 297 binaries link to libselinux, though
I can't say how many of those linked against it directly rather than picking
it up by contamination through a shared library. Furthermore, I've no idea
how many more find it by dlopen.
Not that I know of.
True. I'd rather have separate security for each.
Because, from what I gather, that means my userspace program needs to do
something different, depending on the security model that's currently in force
on a system. Furthermore, I would have to have separate code, as far as I
know, for each security model as there's no commonality in userspace.
I can't just link against libselinux. It might not be there. I'm not going
to tie my program to SELinux either.
Furthermore, I worked out "the right way to do this" with some apparent
SELinux person, and you seemed reasonably accepting of it. Now I have to go
and redo all the work, having had to redo the security stuff a couple of times
already because someone objected. *That* is the main obstacle to getting my
code accepted at the moment, I think.
How about I just stick the context in /etc/cachefilesd.conf as a textual
configuration item and have the daemon pass that as a string to the cachefiles
kernel module, which can then ask LSM if it's valid to set this context as an
override, given the daemon's own security context? That seems entirely
reasonable to me.
David
--
