On Wed, 17 Jul 2019 at 16:02:16 -0700, Casey Schaufler wrote: > We've never had to think about having general rules on > what security modules do before, because with only one > active each could do whatever it wanted without fear of > conflict. If there is already a character that none of > the existing modules use, how would it be wrong to > reserve it? > > Smack disallows the four characters '"/\ because quoting > is too important to ignore and the likelyhood that someone > would confuse labels with paths seemed great. I sniffed > around a little, but couldn't find the sets for SELinux or > AppArmor.
It seems we've been here before, when I added LinuxSecurityLabel to https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-credentials in D-Bus. Recapping the context for those who might have missed it: in D-Bus, processes communicate in a hub-and-spoke topology via a central message bus process, which forwards messages between the other processes. Some other IPC systems would call this a broker. As a result of this indirection, the message bus is the only process in the overall system that is in a position to ask the kernel for the identity of the other processes (credentials(7) and related topics like LSM labels) using unforgeable kernel-guaranteed socket options like SO_PEERCRED, SO_PEERSEC and SO_PEERGROUPS. This means that if two processes communicate via D-Bus and want to know each other's identities, they have to ask the message bus; so the message bus needs a representation for that information. For LSM labels, that representation is LinuxSecurityLabel, which is defined in terms of SO_PEERSEC. At the time that I defined LinuxSecurityLabel, nobody was willing to say for sure that the label was guaranteed to be ASCII or UTF-8 (which is part of the specification for the D-Bus STRING ('s') type), so I had to encode it as an arbitrary ARRAY of BYTE ('ay') rather than as a STRING. I was at least told that the label wouldn't contain embedded '\0', and that if there is a trailing '\0', I can safely canonicalize the string by removing it. Also, at the time that I did that, nobody was willing to say for sure that there was any particular correspondence between the security label obtained by reading /proc/self/attr/current and the security label obtained by getting the SO_PEERSEC socket option: in AppArmor, /proc/self/attr/current is something like "unconfined\n" whereas SO_PEERSEC is either "unconfined" or "unconfined\0" (I forget which), but the consensus seemed to be that there is no guarantee that the presence or absence of a trailing newline wouldn't be significant to some non-AppArmor LSM. If LSM stacking is going to lead to syntactic restrictions being imposed on security labels, please could someone add them to credentials(7) or some other suitable documentation so user-space developers can know where we stand, or tell me what the restrictions and guarantees are so I can propose a documentation patch? Thanks, smcv -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
