On 8/1/2013 11:35 AM, Paul Moore wrote: > On Wednesday, July 31, 2013 02:21:54 PM Casey Schaufler wrote: >> On 7/31/2013 12:39 PM, Paul Moore wrote: >>> On Wednesday, July 31, 2013 09:22:23 AM Casey Schaufler wrote: >>>> On 7/30/2013 3:08 PM, Paul Moore wrote: >>>>> On Thursday, July 25, 2013 11:32:11 AM Casey Schaufler wrote: >>>>>> Subject: [PATCH v14 3/6] LSM: Explicit individual LSM associations >>>>>> >>>>>> Expand the /proc/.../attr interface set to help include >>>>>> LSM specific entries as well as the traditional shared >>>>>> "current", "prev" and "exec" entries. Each LSM that uses >>>>>> one of the traditional interfaces gets it's own interface >>>>>> prefixed with the LSM name for the ones it cares about. >>>>>> Thus, we have "smack.current", "selinux.current" and >>>>>> "apparmor.current" in addition to "current". >>>>>> >>>>>> Add two new interfaces under /sys/kernel/security. >>>>>> The lsm interface displays the comma seperated list of >>>>>> active LSMs. The present interface displays the name >>>>>> of the LSM providing the traditional /proc/.../attr >>>>>> interfaces. User space code should no longer have to >>>>>> grub around in odd places to determine what LSM is >>>>>> being used and thus what data is available to it. >>>>>> >>>>>> Introduce feature specific security operation vectors >>>>>> for NetLabel, XFRM, secmark and presentation in the >>>>>> traditional /proc/.../attr interfaces. This allows >>>>>> proper handling of secids. >>>>> Maybe I missed something, can you elaborate on this, perhaps even >>>>> provide an example for us simple minded folk? >>>> There are a set of facilities that (currently, at least) >>>> can't be shared by multiple LSMs ... >>> I should have been more specific. >>> >>> Thanks for the explanation, but that I understand the problems of stacking >>> LSM/secids, we've had that conversation a few times now. The explanation >>> I was hoping for had to do with this sentence: >>> >>> "Introduce feature specific security operation vectors for >>> NetLabel, XFRM, secmark and presentation in the traditional >>> /proc/.../attr interfaces." >>> >>> Can you explain this a bit more? When I looked at the patch - and maybe >>> I'm missing something - I didn't see anything in /proc that dealt with >>> NetLabel, XFRM, and/or Secmark. >> Just so. I have failed to communicate clearly. >> >> "Each feature that requires support by a single, selected LSM >> is identified by a global pointer to that LSM's security_operations >> structure." >> >> NetLabel, XFRM and secmark are networking interfaces that can >> send the security information from a single LSM along with the >> packets of data. >> >> /proc/.../attr/current and SO_PEERSEC are interfaces that could >> send information from multiple LSMs, but in most cases you have >> to choose one LSM to placate your user space tools. >> >> In all of these cases it is necessary to identify the LSM to use. >> Even though the end use is quite different the mechanism to support >> the identification is the same. > Okay, so if I understand everything correctly, there are no new entries in > /proc relating specifically to NetLabel, XFRM, or Secmark; although there are > new LSM specific entries for the general /proc entries that exist now. Yes? That's correct. There is /sys/kernel/security/present, which tells you which LSM is going to show up in /proc/.../attr/current. Should we have /sys/kernel/security/XFRM, /sys/kernel/security/secmark, /sys/kernel/security/NetLabel and /sys/kernel/security/SO_PEERCRED? -- 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.
