On 12/6/2012 9:11 AM, Kees Cook wrote: > On Thu, Dec 6, 2012 at 8:58 AM, John Johansen > <john.johansen@xxxxxxxxxxxxx> wrote: >> On 12/06/2012 05:49 AM, Tetsuo Handa wrote: >>> John Johansen wrote: >>>> This is not >>>> something I want to do but if that is what is necessary to get stacking done >>>> I will do it. >>> Sharing existing interfaces by managing the format is a thorny path. >>> Future LSM modules, if they are to use existing interfaces, might want to allow >>> attributes up to 4000 bytes when overall length is limited to 4096 bytes. >>> >>>> Of course modifying apparmor doesn't take care of other LSMs so either certain >>>> restrictions have to be part of the api for this interface or as Tetsuo suggests >>>> a new interface would be needed. >>> TOMOYO uses /sys/kernel/security/tomoyo/self_domain (handled by stateless >>> tomoyo_read_self()/tomoyo_write_self()) for reading/updating current thread's >>> attribute and /sys/kernel/security/tomoyo/.process_status (handled by >>> stateful tomoyo_write_pid()/tomoyo_read_pid()) for reading arbitrary thread's >>> attribute. I think that most programs will, if need to access attribute >>> information, need to access only current thread's attribute. Therefore, >>> /sys/kernel/security/tomoyo/self_domain handles only current thread and >>> /sys/kernel/security/tomoyo/.process_status handles arbitrary threads. >>> >>> If AppArmor can migrate from existing /proc/pid/attr/ to its own interfaces >>> like TOMOYO does, we can immediately get LSM stacking with "optionally either >>> SELinux or SMACK" + "optionally AppArmor" + "optionally TOMOYO" + "optionally >>> Yama" + "optionally other LSM modules". SELinux and SMACK are forever exclusive >>> due to conflicts on other hooks. >>> >> So moving apparmor to use its own interface for setting values is reasonable, >> though being able to fall back to /proc/<pid>/attr/* for none stacking cases >> to support older userspace releases would be good. >> >> However getprocattr is a little more problematic as leveraging standard tools >> that have been modified to support the security context (eg. ps -Z, etc) has >> been standard practice, and is used a lot more than writing to /proc/<pid>/attr/* >> Moving to our own interface looses this standard tool support. >> >> There are possible solutions, like multiplexing reading of /proc/<pid>/attr/*, >> but not writes (yes I know its still problematic). > Does it make sense to make attr read-only and leave its output > multiplexed so "ps -Z" output is human readable? This may work long term, but would break backward compatibility. > Regardless, how about we just give attr to the "primary" I much prefer referring to this as the "presented" LSM than as the "primary". All LSMs are equal, one just gets to talk louder. > LSM for now, The disadvantage is that ps -Z, which simply reads /proc/pid/attr/current has to get smarter all of a sudden. > just to land this patch series? It's already a big patch, and I think > it would be beneficial to get the bulk of the stacking logic in. We > can improve the attr handling going forward, since that doesn't seem > to affect the _structure_ of the changes. For my next trick I'll try using the CONFIG_SECURITY_PRESENT value if provided and the first LSM that includes a getprocattr hook otherwise. Let me know if that sounds stupid. -- 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.
