* evm_inode_init_security and module stacking @ 2019-01-18 0:47 Casey Schaufler 2019-01-18 2:31 ` Mimi Zohar 0 siblings, 1 reply; 5+ messages in thread From: Casey Schaufler @ 2019-01-18 0:47 UTC (permalink / raw) To: linux-integrity, Mimi Zohar; +Cc: LSM, Casey Schaufler security_inode_init_security() currently calls at most one of selinux_inode_init_security() and smack_inode_init_security(). It then sends the result to evm_inode_init_security to create the security.evm attribute. This isn't going to work on a system that has both SELinux and Smack. I see two options: - create security.evm with the information from all security modules that provide inode_init_security hooks - create a separate attribute for each module, security.evm-selinux and security.evm-smack in the current case. How would you like to have it work? I am agnostic, although the separate attributes would be easier for the infrastructure. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: evm_inode_init_security and module stacking 2019-01-18 0:47 evm_inode_init_security and module stacking Casey Schaufler @ 2019-01-18 2:31 ` Mimi Zohar 2019-01-18 18:49 ` Casey Schaufler 0 siblings, 1 reply; 5+ messages in thread From: Mimi Zohar @ 2019-01-18 2:31 UTC (permalink / raw) To: Casey Schaufler, linux-integrity; +Cc: LSM On Thu, 2019-01-17 at 16:47 -0800, Casey Schaufler wrote: > security_inode_init_security() currently calls at most one > of selinux_inode_init_security() and smack_inode_init_security(). > It then sends the result to evm_inode_init_security to create > the security.evm attribute. This isn't going to work on a system > that has both SELinux and Smack. Calculating security.evm based on multiple xattrs sounded really familiar. Looking back at the git log, 9d8f13ba3f48 ("security: new security_inode_init_security API adds function callback") addressed filesystems wanting to be able to write all the xattrs at the same time and prepared for multiple LSM xattr support. > I see two options: > - create security.evm with the information from all > security modules that provide inode_init_security hooks > - create a separate attribute for each module, > security.evm-selinux and security.evm-smack in the > current case. > > How would you like to have it work? I am agnostic, although the > separate attributes would be easier for the infrastructure. Having separate attributes for each LSM module would require re- calculating the hmac for each one, any time any of the other file metadata changed. That doesn't sound like a good idea. Mimi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: evm_inode_init_security and module stacking 2019-01-18 2:31 ` Mimi Zohar @ 2019-01-18 18:49 ` Casey Schaufler 2019-01-20 16:42 ` Mimi Zohar 0 siblings, 1 reply; 5+ messages in thread From: Casey Schaufler @ 2019-01-18 18:49 UTC (permalink / raw) To: Mimi Zohar, linux-integrity; +Cc: LSM, Casey Schaufler On 1/17/2019 6:31 PM, Mimi Zohar wrote: > On Thu, 2019-01-17 at 16:47 -0800, Casey Schaufler wrote: >> security_inode_init_security() currently calls at most one >> of selinux_inode_init_security() and smack_inode_init_security(). >> It then sends the result to evm_inode_init_security to create >> the security.evm attribute. This isn't going to work on a system >> that has both SELinux and Smack. > Calculating security.evm based on multiple xattrs sounded really > familiar. Looking back at the git log, 9d8f13ba3f48 ("security: new > security_inode_init_security API adds function callback") addressed > filesystems wanting to be able to write all the xattrs at the same > time and prepared for multiple LSM xattr support. Right. That provides for security.selinux, security.SMACK64 and security.evm at the same time. What it doesn't help with is what goes into security.evm. >> I see two options: >> - create security.evm with the information from all >> security modules that provide inode_init_security hooks >> - create a separate attribute for each module, >> security.evm-selinux and security.evm-smack in the >> current case. >> >> How would you like to have it work? I am agnostic, although the >> separate attributes would be easier for the infrastructure. > Having separate attributes for each LSM module would require re- > calculating the hmac for each one, any time any of the other file > metadata changed. That doesn't sound like a good idea. OK. So it sounds like I need to gather up data from all of the LSMs (e.g. security.selinux, security.SMACK64) and pass the combination to evm_inode_init_security(). Will that work? Will that provide the integrity sub-system what it needs? > Mimi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: evm_inode_init_security and module stacking 2019-01-18 18:49 ` Casey Schaufler @ 2019-01-20 16:42 ` Mimi Zohar 2019-01-20 18:54 ` Casey Schaufler 0 siblings, 1 reply; 5+ messages in thread From: Mimi Zohar @ 2019-01-20 16:42 UTC (permalink / raw) To: Casey Schaufler, linux-integrity; +Cc: LSM On Fri, 2019-01-18 at 10:49 -0800, Casey Schaufler wrote: > On 1/17/2019 6:31 PM, Mimi Zohar wrote: > > On Thu, 2019-01-17 at 16:47 -0800, Casey Schaufler wrote: > >> security_inode_init_security() currently calls at most one > >> of selinux_inode_init_security() and smack_inode_init_security(). > >> It then sends the result to evm_inode_init_security to create > >> the security.evm attribute. This isn't going to work on a system > >> that has both SELinux and Smack. > > Calculating security.evm based on multiple xattrs sounded really > > familiar. Looking back at the git log, 9d8f13ba3f48 ("security: new > > security_inode_init_security API adds function callback") addressed > > filesystems wanting to be able to write all the xattrs at the same > > time and prepared for multiple LSM xattr support. > > Right. That provides for security.selinux, security.SMACK64 > and security.evm at the same time. What it doesn't help with > is what goes into security.evm. > > >> I see two options: > >> - create security.evm with the information from all > >> security modules that provide inode_init_security hooks > >> - create a separate attribute for each module, > >> security.evm-selinux and security.evm-smack in the > >> current case. > >> > >> How would you like to have it work? I am agnostic, although the > >> separate attributes would be easier for the infrastructure. > > Having separate attributes for each LSM module would require re- > > calculating the hmac for each one, any time any of the other file > > metadata changed. That doesn't sound like a good idea. > > OK. So it sounds like I need to gather up data from all of the > LSMs (e.g. security.selinux, security.SMACK64) and pass the combination > to evm_inode_init_security(). Will that work? Will that provide the > integrity sub-system what it needs? Casey, as far as I'm aware only real root, currently, is allowed to write the security xattr domain. If we assume real root is labeling the filesystem with both LSM xattrs, there shouldn't be a problem. I'm not sure how this is going to work from a namespacing/container perspective, which I assume is the impetus for LSM module stacking. I haven't been following Smack. Have you added Smack xattr support or thought about it in the context of "containers"? Are you planning on appending the info to the existing security.SMACK64 label or having separate xattrs for each "container"? Mimi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: evm_inode_init_security and module stacking 2019-01-20 16:42 ` Mimi Zohar @ 2019-01-20 18:54 ` Casey Schaufler 0 siblings, 0 replies; 5+ messages in thread From: Casey Schaufler @ 2019-01-20 18:54 UTC (permalink / raw) To: Mimi Zohar, linux-integrity; +Cc: LSM On 1/20/2019 8:42 AM, Mimi Zohar wrote: > On Fri, 2019-01-18 at 10:49 -0800, Casey Schaufler wrote: >> On 1/17/2019 6:31 PM, Mimi Zohar wrote: >>> On Thu, 2019-01-17 at 16:47 -0800, Casey Schaufler wrote: >>>> security_inode_init_security() currently calls at most one >>>> of selinux_inode_init_security() and smack_inode_init_security(). >>>> It then sends the result to evm_inode_init_security to create >>>> the security.evm attribute. This isn't going to work on a system >>>> that has both SELinux and Smack. >>> Calculating security.evm based on multiple xattrs sounded really >>> familiar. Looking back at the git log, 9d8f13ba3f48 ("security: new >>> security_inode_init_security API adds function callback") addressed >>> filesystems wanting to be able to write all the xattrs at the same >>> time and prepared for multiple LSM xattr support. >> Right. That provides for security.selinux, security.SMACK64 >> and security.evm at the same time. What it doesn't help with >> is what goes into security.evm. >> >>>> I see two options: >>>> - create security.evm with the information from all >>>> security modules that provide inode_init_security hooks >>>> - create a separate attribute for each module, >>>> security.evm-selinux and security.evm-smack in the >>>> current case. >>>> >>>> How would you like to have it work? I am agnostic, although the >>>> separate attributes would be easier for the infrastructure. >>> Having separate attributes for each LSM module would require re- >>> calculating the hmac for each one, any time any of the other file >>> metadata changed. That doesn't sound like a good idea. >> OK. So it sounds like I need to gather up data from all of the >> LSMs (e.g. security.selinux, security.SMACK64) and pass the combination >> to evm_inode_init_security(). Will that work? Will that provide the >> integrity sub-system what it needs? > Casey, as far as I'm aware only real root, currently, is allowed to > write the security xattr domain. If we assume real root is labeling > the filesystem with both LSM xattrs, there shouldn't be a problem. evm_inode_init_security() will get passed the concatenation of security.selinux and security.SMACK64 then. That's easy enough. > I'm not sure how this is going to work from a namespacing/container > perspective, which I assume is the impetus for LSM module stacking. It's one of the use cases. New LSMs that want to use blobs, including Landlock and SARA, are also important. I even know someone who wants to use Smack and AppArmor in a complimentary fashon. > I haven't been following Smack. Have you added Smack xattr support or > thought about it in the context of "containers"? Are you planning on > appending the info to the existing security.SMACK64 label or having > separate xattrs for each "container"? Samsung had a pretty complete implementation for Smack "namespaces", but they decided on a different technical approach to their problem. No one has picked it back up. It used a label aliasing mechanism, very much like what user namespaces do for UIDs. All attributes saved to disk are native. The mapping only exists for the life of the namespace. > > Mimi > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-01-20 18:56 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-18 0:47 evm_inode_init_security and module stacking Casey Schaufler 2019-01-18 2:31 ` Mimi Zohar 2019-01-18 18:49 ` Casey Schaufler 2019-01-20 16:42 ` Mimi Zohar 2019-01-20 18:54 ` Casey Schaufler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).