Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > That sounds too SELinux specific. How do I do it so that it works for any > > LSM? > > You can't. There is no LSM for userspace; LSM specifically disavowed > any common userspace API, and that was one of our original > objections/concerns about it. So, basically, userspace programs (outside of security tools) aren't supposed to need access to the security infrastructure? > > Is linking against libselinux is a viable option if it's not available under > > all LSM models? Is it available under all LSM models? Perhaps Casey can > > answer this one. > > Nope, they would all have their own libraries, if they have a library at > all. But that isn't your problem 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. > - your kernel interface should be generic, and your LSM hooks should be > generic, but your userspace isn't required to be. Have a look at how many > programs in the distribution currently link against libselinux, whether > directly or by dlopen'ing it. 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. > > > > I use to do that, but someone objected... Possibly Karl MacMillan. > > > > > > Yes, but I think I disagreed then too. > > > > So, who's right? > > Karl isn't a maintainer of the SELinux kernel code. And I had thought > that even he had reconsidered this idea after further discussion. Not that I know of. > > > It doesn't fit with how other users of security_kernel_act_as() will > > > likely want to work (they will want to just set the context to a > > > specified value, whether one obtained from the client or from some local > > > source), nor with how type transitions normally work (exec, with the > > > program type as the second type field). I think it will just cause > > > confusion and subtle breakage. > > > > It's causing me lots of confusion as it is. I have been / am being told by > > different people to do different things just in dealing with SELinux, and > > various people are raising extra requirements or restrictions beyond that. > > There doesn't seem to be a consensus. > > > > It sounds like the best option is just to have the kernel nick the userspace > > daemon's security context and use that as is, and junk all the restrictions on > > what the daemon can do so that the kernel isn't too restricted. > > Well, you could do that, if that meets your needs, but it doesn't sound > very optimal either. True. I'd rather have separate security for each. > Why are you opposed to having userspace determine the context and write it > to a cachefiles interface, 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 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
