* 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ messages in thread
* evm_inode_init_security and module stacking
@ 2017-08-19 0:14 Casey Schaufler
0 siblings, 0 replies; 6+ messages in thread
From: Casey Schaufler @ 2017-08-19 0:14 UTC (permalink / raw)
To: linux-security-module
I'm looking at the code in evm_inode_init_security
and it looks like there's no way it could be taught
to deal with there being more than one security
attribute being controlled. This is because the
EVM data is stored in XATTR_EVM_SUFFIX, for which
there is only one per file. On a system with both
SELinux and Smack, there isn't a place to put the
EVM attribute for whichever module comes second.
Or, as has often been the case, am I missing something?
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-01-20 18:56 UTC | newest]
Thread overview: 6+ 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
-- strict thread matches above, loose matches on Subject: below --
2017-08-19 0:14 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).