Re: Preferred subj= with multiple LSMs
On 7/22/2019 3:30 PM, Paul Moore wrote: > On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler > wrote: >> On 7/22/2019 1:50 PM, James Morris wrote: >>> On Fri, 19 Jul 2019, Paul Moore 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? "We've never had to think about having general rules on what security modules do before..." We famously haven't imposed restrictions on the label format before now, and this seems like a pretty poor reason to start. >>> Agreed. >> In a follow on thread >> >> https://www.spinics.net/lists/linux-security-module/msg29996.html >> >> we've been discussing the needs of dbus-daemon in a multiple LSM >> environment. I suggest that if supporting dbus well is assisted by >> making reasonable restrictions on what constitutes a valid LSM >> "context" that we have a good reason. While there are ways to >> present groups of arbitrary hunks of data, why would we want to? > I continue to believe that restrictions on the label format are a bad > idea, and I further believe that multiplexing the labels is going to > be a major problem that will haunt us for many, many years. If we are > going to support multiple simultaneous LSMs I think we need to find a > way to represent those labels independently. Let's review the bidding: Audit wants to maintain backward compatibility while also getting the information about multiple subject and object labels. The current proposal: ... subj=a:b:c:d \ ... obj=e:f:g:h obj_selinux=e:f:g:h obj_mumble=Crivens \ ... subj_selinux=a:b:c:d subj_mumble=Feegle \ ... where obj_ and subj_ are only provided if there's more than one active "display" LSM. Dbus wants an atomic fetch of the security attributes from a socket and from a /proc entry. We don't want to break compatibility, so new interfaces are provided: SO_PEERCONTEXT - packet label in the "Hideous" format /proc/.../attr/context - process label in the "Hideous" format Legacy programs want the security attributes from a socket and from a /proc entry. Since they don't know how to differentiate which security module is active, these are controlled by the "display", which defaults to the first module loaded that provides a secid_to_secctx() hook. (not quite the definition, but close enough) SO_PEERSEC - "display" LSM packet label in module native format /proc/.../attr/display - set/get the "display" value /proc/.../attr/current - "display" LSM process label in module native format /proc/.../attr/smack/current - Smack process label in module native format A classic Android, Tizen, Fedora or Ubuntu system will continue to use these interfaces and see no difference in behavior. A system that really wants to use multiple "display"ing modules will have the same issues that dbus has, and will likely convert to the new, "hideous" interfaces, especially if a liblsm (NOT libsecurity!) is provided. -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: Preferred subj= with multiple LSMs
On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler wrote: > On 7/22/2019 1:50 PM, James Morris wrote: > > On Fri, 19 Jul 2019, Paul Moore 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? > >> "We've never had to think about having general rules on what security > >> modules do before..." > >> > >> We famously haven't imposed restrictions on the label format before > >> now, and this seems like a pretty poor reason to start. > > Agreed. > > In a follow on thread > > https://www.spinics.net/lists/linux-security-module/msg29996.html > > we've been discussing the needs of dbus-daemon in a multiple LSM > environment. I suggest that if supporting dbus well is assisted by > making reasonable restrictions on what constitutes a valid LSM > "context" that we have a good reason. While there are ways to > present groups of arbitrary hunks of data, why would we want to? I continue to believe that restrictions on the label format are a bad idea, and I further believe that multiplexing the labels is going to be a major problem that will haunt us for many, many years. If we are going to support multiple simultaneous LSMs I think we need to find a way to represent those labels independently. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: Preferred subj= with multiple LSMs
On 7/22/2019 1:50 PM, James Morris wrote: > On Fri, 19 Jul 2019, Paul Moore 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? >> "We've never had to think about having general rules on what security >> modules do before..." >> >> We famously haven't imposed restrictions on the label format before >> now, and this seems like a pretty poor reason to start. > Agreed. In a follow on thread https://www.spinics.net/lists/linux-security-module/msg29996.html we've been discussing the needs of dbus-daemon in a multiple LSM environment. I suggest that if supporting dbus well is assisted by making reasonable restrictions on what constitutes a valid LSM "context" that we have a good reason. While there are ways to present groups of arbitrary hunks of data, why would we want to? -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: Preferred subj= with multiple LSMs
On Fri, 19 Jul 2019, Paul Moore 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? > > "We've never had to think about having general rules on what security > modules do before..." > > We famously haven't imposed restrictions on the label format before > now, and this seems like a pretty poor reason to start. Agreed. -- James Morris -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: Dbus and multiple LSMs (was Preferred subj= with multiple LSMs)
On 7/22/2019 4:36 AM, Simon McVittie wrote: > On Fri, 19 Jul 2019 at 13:02:24 -0700, Casey Schaufler wrote: >> On 7/19/2019 11:47 AM, Simon McVittie wrote: >>> I was hoping the syscall wrappers in glibc would be a viable user-space >>> interface to the small amount of LSM stuff that dbus needs to use in an >>> LSM-agnostic way. >> I don't see how to do that without making the Fedora and Ubuntu user space >> environments [not] remain functional. > What I was thinking of was a second, parallel kernel <-> user-space > interface (like the SO_PEERSECLABELS that I suggested) for future/updated > user-space components. SO_PEERSEC would continue to return some > hopefully-backwards-compatible thing, but would be deprecated, because it > cannot fully represent the reality of LSM stacking while remaining > backwards-compatible. I will propose SO_PEERCONTEXT and /proc/.../attr/stack/context, both of which will use the Hideous format, in the next round. I appreciate the suggestion and discussion. >> I see display being used in scripts: >> >> echo apparmor > /proc/self/attr/display >> apparmor-do-stuff --options --deamon >> >> much more than inside new or updated programs. > Note that this implicitly relies on echo being a shell builtin, which > is common but not guaranteed (I don't think). It would work in bash or > dash, though. Yes, echo being built-in can't be guaranteed. Most shells have some way of doing the equivalent. > If apparmor-do-stuff no longer works, and you have to wrap a shell > script around it, isn't that the same amount of user-space breakage as > if apparmor-do-stuff no longer works and you have to install a newer > version that does work? True when there is such a newer version. I'm sure you're aware of how much system software out there hasn't been updated in this century. > Either way, the sysadmin must take action to > change user-space components. I think the attr/display thing only reduces > the magnitude of the user-space changes required to catch up, and doesn't > eliminate the fact that those changes were needed. Agreed. It's a tool for the times of transition. >>> Lots of programs (including dbus-daemon) fork-and-exec arbitrary >>> child processes that come from a different codebase not under our >>> control and aren't necessarily LSM-stacking-aware. I don't really want >>> to have to reset /proc/self/attr/display in our increasingly crowded >>> after-fork-but-before-exec code path >> My hope is that new and updated programs will have to tools >> they need to get it right, and that those that don't won't >> fall over on a well configured system. > The problem I see here is that if we assume dbus-daemon is a new/updated > program that has set /proc/self/attr/display = "hideous" in order to get > the full stack of labels for its peer processes, then it will be causing > side-effects on its separately-maintained child processes - they will > no longer be able to benefit from the backwards-compatility thing where > /proc/self/attr/display (effectively) defaults to the first LSM that > has labels, because dbus-daemon overrode that (unless dbus-daemon takes > action to reverse it between fork and exec). This partially defeats the > semi-backwards-compatible handling of the existing kernel interfaces. Point. /proc/self/attr/stack/context and SO_PEERCONTEXT comprise a better, more reliable solution. > If dbus-daemon could read SO_PEERSECLABELS instead of SO_PEERSEC and > read /proc//attr/current_stack instead of /proc//attr/current, > leaving /proc/self/attr/display untouched, then this concern would go away. I agree. > Similarly, dbus-daemon can be linked to libselinux and/or libapparmor > (on Debian it's linked to both, even in the non-stackable present, > and the right one for the kernel configuration is chosen at runtime). > If one of those libraries wrote to /proc/self/attr/display, then the rest > of dbus-daemon's main thread and all child processes would implicitly be > getting the result of that - even if dbus-daemon itself had not yet been > updated for stacked LSMs (in which case it cannot be expected to reverse > their action between fork and exec, because it's an older codebase that > doesn't yet know that "big" LSMs can be stacked). Yes. > So I think libselinux and libapparmor should be enhanced to use > new kernel interfaces that get the label they want to get (either > just that label, or all the labels), instead of being enhanced to > write /proc/self/attr/display to change the meaning of old kernel > interfaces. Otherwise they can break other code in their process or > their subprocesses. The AppArmor team is already moving away from using the /proc/self/attr intefaces. /proc/self/attr/smack is already there, and the transition begun. The SELinux developers seem firmly set in the position that there is no reason they should ever change. In the long term I think we'll get the conflict sorted out. It's hard to say what value of "long term" we're looking at.
