* vfs_getxattr_alloc() problem
@ 2020-04-21 10:58 Roberto Sassu
2020-04-23 23:51 ` Mimi Zohar
0 siblings, 1 reply; 6+ messages in thread
From: Roberto Sassu @ 2020-04-21 10:58 UTC (permalink / raw)
To: Mimi Zohar; +Cc: linux-integrity@vger.kernel.org, Silviu Vlasceanu
Hi Mimi
I found a problem in the calculation of the EVM digest.
If an xattr is in the security domain, vfs_getxattr() calls xattr_getsecurity(),
which is implemented by LSMs. vfs_getxattr_alloc() instead calls directly
the filesystem function to read xattrs.
The problem arises for example when you have a file with a portable
signature on the correct SELinux label (with \0) and you set security.selinux
manually:
setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" cat
Although the length passed is 26 bytes (without \0), you get:
# attr -l cat
Attribute "selinux" has a 27 byte value for cat
which includes \0.
From user space, evmctl does not complain (the signature is ok) because
it calculates the EVM digest with \0, but EVM verification fails (because it
calculates the digest without \0).
Should this problem be fixed?
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vfs_getxattr_alloc() problem
2020-04-21 10:58 vfs_getxattr_alloc() problem Roberto Sassu
@ 2020-04-23 23:51 ` Mimi Zohar
2020-04-24 14:32 ` Roberto Sassu
0 siblings, 1 reply; 6+ messages in thread
From: Mimi Zohar @ 2020-04-23 23:51 UTC (permalink / raw)
To: Roberto Sassu, Matthew Garrett
Cc: linux-integrity@vger.kernel.org, Silviu Vlasceanu
[Cc'ing Matthew]
Hi Roberto,
On Tue, 2020-04-21 at 10:58 +0000, Roberto Sassu wrote:
> Hi Mimi
>
> I found a problem in the calculation of the EVM digest.
>
> If an xattr is in the security domain, vfs_getxattr() calls xattr_getsecurity(),
> which is implemented by LSMs. vfs_getxattr_alloc() instead calls directly
> the filesystem function to read xattrs.
>
> The problem arises for example when you have a file with a portable
> signature on the correct SELinux label (with \0) and you set security.selinux
> manually:
>
> setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" cat
>
> Although the length passed is 26 bytes (without \0), you get:
>
> # attr -l cat
> Attribute "selinux" has a 27 byte value for cat
>
> which includes \0.
>
> From user space, evmctl does not complain (the signature is ok) because
> it calculates the EVM digest with \0, but EVM verification fails (because it
> calculates the digest without \0).
>
> Should this problem be fixed?
I don't seem to be having any problems verifying the EVM immutable &
portable signatures. To test, I've copied a properly labeled file
twice, once with the "--preserve=xattr" and once without it. I signed
the properly labeled file with the EVM immutable & portable signature.
On the other file, I first set the selinux label before signing it.
If there was a problem manually writing the SELinux label, the
security.evm labels would be different, which they aren't.
Matthew, are you able to reproduce Roberto's problem?
Mimi
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: vfs_getxattr_alloc() problem
2020-04-23 23:51 ` Mimi Zohar
@ 2020-04-24 14:32 ` Roberto Sassu
2020-04-27 18:54 ` Mimi Zohar
0 siblings, 1 reply; 6+ messages in thread
From: Roberto Sassu @ 2020-04-24 14:32 UTC (permalink / raw)
To: Mimi Zohar, Matthew Garrett
Cc: linux-integrity@vger.kernel.org, Silviu Vlasceanu
> -----Original Message-----
> From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> Sent: Friday, April 24, 2020 1:52 AM
> To: Roberto Sassu <roberto.sassu@huawei.com>; Matthew Garrett
> <mjg59@google.com>
> Cc: linux-integrity@vger.kernel.org; Silviu Vlasceanu
> <Silviu.Vlasceanu@huawei.com>
> Subject: Re: vfs_getxattr_alloc() problem
>
> [Cc'ing Matthew]
>
> Hi Roberto,
>
> On Tue, 2020-04-21 at 10:58 +0000, Roberto Sassu wrote:
> > Hi Mimi
> >
> > I found a problem in the calculation of the EVM digest.
> >
> > If an xattr is in the security domain, vfs_getxattr() calls xattr_getsecurity(),
> > which is implemented by LSMs. vfs_getxattr_alloc() instead calls directly
> > the filesystem function to read xattrs.
> >
> > The problem arises for example when you have a file with a portable
> > signature on the correct SELinux label (with \0) and you set
> security.selinux
> > manually:
> >
> > setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" cat
> >
> > Although the length passed is 26 bytes (without \0), you get:
> >
> > # attr -l cat
> > Attribute "selinux" has a 27 byte value for cat
> >
> > which includes \0.
> >
> > From user space, evmctl does not complain (the signature is ok) because
> > it calculates the EVM digest with \0, but EVM verification fails (because it
> > calculates the digest without \0).
> >
> > Should this problem be fixed?
>
> I don't seem to be having any problems verifying the EVM immutable &
> portable signatures. To test, I've copied a properly labeled file
> twice, once with the "--preserve=xattr" and once without it. I signed
> the properly labeled file with the EVM immutable & portable signature.
> On the other file, I first set the selinux label before signing it.
> If there was a problem manually writing the SELinux label, the
> security.evm labels would be different, which they aren't.
[root@vm demo]# ls -lZ /bin/cat
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 85520 Apr 24 16:20 /bin/cat
[root@vm demo]# evmctl sign -o -a sha256 --imahash --key $PWD/signing_key.pem /bin/cat -v -v
hash(sha256): 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
name: security.selinux, size: 27
73797374656d5f753a6f626a6563745f723a62696e5f743a733000
no xattr: security.SMACK64
no xattr: security.apparmor
name: security.ima, size: 34
0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
no xattr: security.capability
calc_evm_hash:532 hmac_misc (24): 0000000000000000000000000000000000000000ed810000
hash(sha256): 331e36ce1b32374a22e12df28b58d79536c0ee97ba01451bd60343191c073b55
calc_keyid_v2:735 keyid: aecec286
keyid: aecec286
evm/ima signature: 520 bytes
...
[root@vm demo]# cat
^C
[root@vm demo]# setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" /bin/cat
[root@vm demo]# evmctl verify -o -a sha256 --imahash /bin/cat -v -v
calc_keyid_v2:735 keyid: aecec286
keyid: aecec286
key 1: aecec286 /etc/keys/x509_evm.der
name: security.selinux, size: 27
73797374656d5f753a6f626a6563745f723a62696e5f743a733000
no xattr: security.SMACK64
no xattr: security.apparmor
name: security.ima, size: 34
0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
no xattr: security.capability
calc_evm_hash:532 hmac_misc (24): 0000000000000000000000000000000000000000ed810000
hash(sha256): 331e36ce1b32374a22e12df28b58d79536c0ee97ba01451bd60343191c073b55
/bin/cat: verification is OK
[root@vm demo]# cat
-bash: /usr/bin/cat: Permission denied
[root@vm demo]#
It fails because the actual xattr in the filesystem is:
name: security.selinux, size: 26
73797374656d5f753a6f626a6563745f723a62696e5f743a7330
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vfs_getxattr_alloc() problem
2020-04-24 14:32 ` Roberto Sassu
@ 2020-04-27 18:54 ` Mimi Zohar
2020-04-27 19:19 ` Mimi Zohar
0 siblings, 1 reply; 6+ messages in thread
From: Mimi Zohar @ 2020-04-27 18:54 UTC (permalink / raw)
To: Roberto Sassu, Matthew Garrett
Cc: linux-integrity@vger.kernel.org, Silviu Vlasceanu
On Fri, 2020-04-24 at 14:32 +0000, Roberto Sassu wrote:
> > Hi Roberto,
> >
> > On Tue, 2020-04-21 at 10:58 +0000, Roberto Sassu wrote:
> > > Hi Mimi
> > >
> > > I found a problem in the calculation of the EVM digest.
> > >
> > > If an xattr is in the security domain, vfs_getxattr() calls xattr_getsecurity(),
> > > which is implemented by LSMs. vfs_getxattr_alloc() instead calls directly
> > > the filesystem function to read xattrs.
> > >
> > > The problem arises for example when you have a file with a portable
> > > signature on the correct SELinux label (with \0) and you set
> > security.selinux
> > > manually:
> > >
> > > setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" cat
> > >
> > > Although the length passed is 26 bytes (without \0), you get:
> > >
> > > # attr -l cat
> > > Attribute "selinux" has a 27 byte value for cat
> > >
> > > which includes \0.
> > >
> > > From user space, evmctl does not complain (the signature is ok) because
> > > it calculates the EVM digest with \0, but EVM verification fails (because it
> > > calculates the digest without \0).
> > >
> > > Should this problem be fixed?
> >
> > I don't seem to be having any problems verifying the EVM immutable &
> > portable signatures. To test, I've copied a properly labeled file
> > twice, once with the "--preserve=xattr" and once without it. I signed
> > the properly labeled file with the EVM immutable & portable signature.
> > On the other file, I first set the selinux label before signing it.
> > If there was a problem manually writing the SELinux label, the
> > security.evm labels would be different, which they aren't.
>
> [root@vm demo]# ls -lZ /bin/cat
> -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 85520 Apr 24 16:20 /bin/cat
> [root@vm demo]# evmctl sign -o -a sha256 --imahash --key $PWD/signing_key.pem /bin/cat -v -v
> hash(sha256): 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
> name: security.selinux, size: 27
> 73797374656d5f753a6f626a6563745f723a62696e5f743a733000
> no xattr: security.SMACK64
> no xattr: security.apparmor
> name: security.ima, size: 34
> 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
> no xattr: security.capability
> calc_evm_hash:532 hmac_misc (24): 0000000000000000000000000000000000000000ed810000
> hash(sha256): 331e36ce1b32374a22e12df28b58d79536c0ee97ba01451bd60343191c073b55
> calc_keyid_v2:735 keyid: aecec286
> keyid: aecec286
> evm/ima signature: 520 bytes
> ...
> [root@vm demo]# cat
> ^C
> [root@vm demo]# setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" /bin/cat
In the past, when I looked at writing the same SELinux label, there
was some performance improvement that only updated the label if the
label actually changed. Unless things have changed since, I don't
think the same selinux label is rewritten.
> [root@vm demo]# evmctl verify -o -a sha256 --imahash /bin/cat -v -v
> calc_keyid_v2:735 keyid: aecec286
> keyid: aecec286
> key 1: aecec286 /etc/keys/x509_evm.der
> name: security.selinux, size: 27
> 73797374656d5f753a6f626a6563745f723a62696e5f743a733000
> no xattr: security.SMACK64
> no xattr: security.apparmor
> name: security.ima, size: 34
> 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
> no xattr: security.capability
> calc_evm_hash:532 hmac_misc (24): 0000000000000000000000000000000000000000ed810000
> hash(sha256): 331e36ce1b32374a22e12df28b58d79536c0ee97ba01451bd60343191c073b55
> /bin/cat: verification is OK
> [root@vm demo]# cat
> -bash: /usr/bin/cat: Permission denied
> [root@vm demo]#
>
> It fails because the actual xattr in the filesystem is:
>
> name: security.selinux, size: 26
> 73797374656d5f753a6f626a6563745f723a62696e5f743a7330
Looking at security/selinux/hooks.c: I'm seeing a
comment selinux_inode_setxattr() that says:
/* We strip a nul only if it is at the end, otherwise the
* context contains a nul and we should audit that */
Mimi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vfs_getxattr_alloc() problem
2020-04-27 18:54 ` Mimi Zohar
@ 2020-04-27 19:19 ` Mimi Zohar
2020-04-28 7:02 ` Roberto Sassu
0 siblings, 1 reply; 6+ messages in thread
From: Mimi Zohar @ 2020-04-27 19:19 UTC (permalink / raw)
To: Roberto Sassu, Matthew Garrett
Cc: linux-integrity@vger.kernel.org, Silviu Vlasceanu
On Mon, 2020-04-27 at 14:54 -0400, Mimi Zohar wrote:
> On Fri, 2020-04-24 at 14:32 +0000, Roberto Sassu wrote:
> > > Hi Roberto,
> > >
> > > On Tue, 2020-04-21 at 10:58 +0000, Roberto Sassu wrote:
> > > > Hi Mimi
> > > >
> > > > I found a problem in the calculation of the EVM digest.
> > > >
> > > > If an xattr is in the security domain, vfs_getxattr() calls xattr_getsecurity(),
> > > > which is implemented by LSMs. vfs_getxattr_alloc() instead calls directly
> > > > the filesystem function to read xattrs.
> > > >
> > > > The problem arises for example when you have a file with a portable
> > > > signature on the correct SELinux label (with \0) and you set
> > > security.selinux
> > > > manually:
> > > >
> > > > setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" cat
> > > >
> > > > Although the length passed is 26 bytes (without \0), you get:
> > > >
> > > > # attr -l cat
> > > > Attribute "selinux" has a 27 byte value for cat
> > > >
> > > > which includes \0.
> > > >
> > > > From user space, evmctl does not complain (the signature is ok) because
> > > > it calculates the EVM digest with \0, but EVM verification fails (because it
> > > > calculates the digest without \0).
> > > >
> > > > Should this problem be fixed?
> > >
> > > I don't seem to be having any problems verifying the EVM immutable &
> > > portable signatures. To test, I've copied a properly labeled file
> > > twice, once with the "--preserve=xattr" and once without it. I signed
> > > the properly labeled file with the EVM immutable & portable signature.
> > > On the other file, I first set the selinux label before signing it.
> > > If there was a problem manually writing the SELinux label, the
> > > security.evm labels would be different, which they aren't.
> >
> > [root@vm demo]# ls -lZ /bin/cat
> > -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 85520 Apr 24 16:20 /bin/cat
> > [root@vm demo]# evmctl sign -o -a sha256 --imahash --key $PWD/signing_key.pem /bin/cat -v -v
> > hash(sha256): 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
> > name: security.selinux, size: 27
> > 73797374656d5f753a6f626a6563745f723a62696e5f743a733000
> > no xattr: security.SMACK64
> > no xattr: security.apparmor
> > name: security.ima, size: 34
> > 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
> > no xattr: security.capability
> > calc_evm_hash:532 hmac_misc (24): 0000000000000000000000000000000000000000ed810000
> > hash(sha256): 331e36ce1b32374a22e12df28b58d79536c0ee97ba01451bd60343191c073b55
> > calc_keyid_v2:735 keyid: aecec286
> > keyid: aecec286
> > evm/ima signature: 520 bytes
> > ...
> > [root@vm demo]# cat
> > ^C
> > [root@vm demo]# setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" /bin/cat
>
> In the past, when I looked at writing the same SELinux label, there
> was some performance improvement that only updated the label if the
> label actually changed. Unless things have changed since, I don't
> think the same selinux label is rewritten.
>
> > [root@vm demo]# evmctl verify -o -a sha256 --imahash /bin/cat -v -v
> > calc_keyid_v2:735 keyid: aecec286
> > keyid: aecec286
> > key 1: aecec286 /etc/keys/x509_evm.der
> > name: security.selinux, size: 27
> > 73797374656d5f753a6f626a6563745f723a62696e5f743a733000
> > no xattr: security.SMACK64
> > no xattr: security.apparmor
> > name: security.ima, size: 34
> > 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10bc6
> > no xattr: security.capability
> > calc_evm_hash:532 hmac_misc (24): 0000000000000000000000000000000000000000ed810000
> > hash(sha256): 331e36ce1b32374a22e12df28b58d79536c0ee97ba01451bd60343191c073b55
> > /bin/cat: verification is OK
> > [root@vm demo]# cat
> > -bash: /usr/bin/cat: Permission denied
> > [root@vm demo]#
> >
> > It fails because the actual xattr in the filesystem is:
> >
> > name: security.selinux, size: 26
> > 73797374656d5f753a6f626a6563745f723a62696e5f743a7330
>
> Looking at security/selinux/hooks.c: I'm seeing a
> comment selinux_inode_setxattr() that says:
>
> /* We strip a nul only if it is at the end, otherwise the
> * context contains a nul and we should audit that */
strace shows setxattr is writing 26 bytes:
setxattr("/bin/cat-test", "security.selinux",
"system_u:object_r:bin_t:s0", 26, 0) = 0
Mimi
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: vfs_getxattr_alloc() problem
2020-04-27 19:19 ` Mimi Zohar
@ 2020-04-28 7:02 ` Roberto Sassu
0 siblings, 0 replies; 6+ messages in thread
From: Roberto Sassu @ 2020-04-28 7:02 UTC (permalink / raw)
To: Mimi Zohar, Matthew Garrett
Cc: linux-integrity@vger.kernel.org, Silviu Vlasceanu
> -----Original Message-----
> From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> Sent: Monday, April 27, 2020 9:20 PM
> To: Roberto Sassu <roberto.sassu@huawei.com>; Matthew Garrett
> <mjg59@google.com>
> Cc: linux-integrity@vger.kernel.org; Silviu Vlasceanu
> <Silviu.Vlasceanu@huawei.com>
> Subject: Re: vfs_getxattr_alloc() problem
>
> On Mon, 2020-04-27 at 14:54 -0400, Mimi Zohar wrote:
> > On Fri, 2020-04-24 at 14:32 +0000, Roberto Sassu wrote:
> > > > Hi Roberto,
> > > >
> > > > On Tue, 2020-04-21 at 10:58 +0000, Roberto Sassu wrote:
> > > > > Hi Mimi
> > > > >
> > > > > I found a problem in the calculation of the EVM digest.
> > > > >
> > > > > If an xattr is in the security domain, vfs_getxattr() calls
> xattr_getsecurity(),
> > > > > which is implemented by LSMs. vfs_getxattr_alloc() instead calls
> directly
> > > > > the filesystem function to read xattrs.
> > > > >
> > > > > The problem arises for example when you have a file with a portable
> > > > > signature on the correct SELinux label (with \0) and you set
> > > > security.selinux
> > > > > manually:
> > > > >
> > > > > setfattr -n security.selinux -v "system_u:object_r:bin_t:s0" cat
> > > > >
> > > > > Although the length passed is 26 bytes (without \0), you get:
> > > > >
> > > > > # attr -l cat
> > > > > Attribute "selinux" has a 27 byte value for cat
> > > > >
> > > > > which includes \0.
> > > > >
> > > > > From user space, evmctl does not complain (the signature is ok)
> because
> > > > > it calculates the EVM digest with \0, but EVM verification fails
> (because it
> > > > > calculates the digest without \0).
> > > > >
> > > > > Should this problem be fixed?
> > > >
> > > > I don't seem to be having any problems verifying the EVM immutable
> &
> > > > portable signatures. To test, I've copied a properly labeled file
> > > > twice, once with the "--preserve=xattr" and once without it. I signed
> > > > the properly labeled file with the EVM immutable & portable signature.
> > > > On the other file, I first set the selinux label before signing it.
> > > > If there was a problem manually writing the SELinux label, the
> > > > security.evm labels would be different, which they aren't.
> > >
> > > [root@vm demo]# ls -lZ /bin/cat
> > > -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 85520 Apr 24 16:20
> /bin/cat
> > > [root@vm demo]# evmctl sign -o -a sha256 --imahash --key
> $PWD/signing_key.pem /bin/cat -v -v
> > > hash(sha256):
> 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10
> bc6
> > > name: security.selinux, size: 27
> > > 73797374656d5f753a6f626a6563745f723a62696e5f743a733000
> > > no xattr: security.SMACK64
> > > no xattr: security.apparmor
> > > name: security.ima, size: 34
> > >
> 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10
> bc6
> > > no xattr: security.capability
> > > calc_evm_hash:532 hmac_misc (24):
> 0000000000000000000000000000000000000000ed810000
> > > hash(sha256):
> 331e36ce1b32374a22e12df28b58d79536c0ee97ba01451bd60343191c073b55
> > > calc_keyid_v2:735 keyid: aecec286
> > > keyid: aecec286
> > > evm/ima signature: 520 bytes
> > > ...
> > > [root@vm demo]# cat
> > > ^C
> > > [root@vm demo]# setfattr -n security.selinux -v
> "system_u:object_r:bin_t:s0" /bin/cat
> >
> > In the past, when I looked at writing the same SELinux label, there
> > was some performance improvement that only updated the label if the
> > label actually changed. Unless things have changed since, I don't
> > think the same selinux label is rewritten.
> >
> > > [root@vm demo]# evmctl verify -o -a sha256 --imahash /bin/cat -v -v
> > > calc_keyid_v2:735 keyid: aecec286
> > > keyid: aecec286
> > > key 1: aecec286 /etc/keys/x509_evm.der
> > > name: security.selinux, size: 27
> > > 73797374656d5f753a6f626a6563745f723a62696e5f743a733000
> > > no xattr: security.SMACK64
> > > no xattr: security.apparmor
> > > name: security.ima, size: 34
> > >
> 0404d3d78d8249317ed50056ec7d04da382488f36a6127f4e9161792d97f13e10
> bc6
> > > no xattr: security.capability
> > > calc_evm_hash:532 hmac_misc (24):
> 0000000000000000000000000000000000000000ed810000
> > > hash(sha256):
> 331e36ce1b32374a22e12df28b58d79536c0ee97ba01451bd60343191c073b55
> > > /bin/cat: verification is OK
> > > [root@vm demo]# cat
> > > -bash: /usr/bin/cat: Permission denied
> > > [root@vm demo]#
> > >
> > > It fails because the actual xattr in the filesystem is:
> > >
> > > name: security.selinux, size: 26
> > > 73797374656d5f753a6f626a6563745f723a62696e5f743a7330
> >
> > Looking at security/selinux/hooks.c: I'm seeing a
> > comment selinux_inode_setxattr() that says:
> >
> > /* We strip a nul only if it is at the end, otherwise the
> > * context contains a nul and we should audit that */
>
> strace shows setxattr is writing 26 bytes:
>
> setxattr("/bin/cat-test", "security.selinux",
> "system_u:object_r:bin_t:s0", 26, 0) = 0
Yes, but SELinux fixes the label and adds \0:
static int selinux_inode_setxattr(struct dentry *dentry, const char *name,
const void *value, size_t size, int flags)
{
[...]
rc = security_context_to_sid(&selinux_state, value, size, &newsid,
GFP_KERNEL);
static int security_context_to_sid_core(struct selinux_state *state,
const char *scontext, u32 scontext_len,
u32 *sid, u32 def_sid, gfp_t gfp_flags,
int force)
{
[...]
/* Copy the string to allow changes and ensure a NUL terminator */
scontext2 = kmemdup_nul(scontext, scontext_len, gfp_flags);
When evmctl reads from user space, the kernel does:
ssize_t
vfs_getxattr(struct dentry *dentry, const char *name, void *value, size_t size)
{
[...]
if (!strncmp(name, XATTR_SECURITY_PREFIX,
XATTR_SECURITY_PREFIX_LEN)) {
const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
int ret = xattr_getsecurity(inode, suffix, value, size);
static int selinux_inode_getsecurity(struct inode *inode, const char *name, void **buffer, bool alloc)
{
[...]
error = security_sid_to_context(&selinux_state, isec->sid,
&context, &size);
evmctl gets the string of 27 bytes with the \0, which is not the content
stored in the filesystem but the SELinux translation of the sid.
Instead EVM takes a different path:
ssize_t
vfs_getxattr_alloc(struct dentry *dentry, const char *name, char **xattr_value,
size_t xattr_size, gfp_t flags)
{
[...]
error = handler->get(handler, dentry, inode, name, NULL, 0);
so, it gets 26 bytes, not 27. This is why permission is denied.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-04-28 7:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-21 10:58 vfs_getxattr_alloc() problem Roberto Sassu
2020-04-23 23:51 ` Mimi Zohar
2020-04-24 14:32 ` Roberto Sassu
2020-04-27 18:54 ` Mimi Zohar
2020-04-27 19:19 ` Mimi Zohar
2020-04-28 7:02 ` Roberto Sassu
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).