From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
Matthew Garrett <mjg59@google.com>
Cc: "linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>
Subject: Re: vfs_getxattr_alloc() problem
Date: Mon, 27 Apr 2020 15:19:55 -0400 [thread overview]
Message-ID: <1588015195.16086.3.camel@linux.ibm.com> (raw)
In-Reply-To: <1588013688.4553.7.camel@linux.ibm.com>
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
next prev parent reply other threads:[~2020-04-27 19:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2020-04-28 7:02 ` Roberto Sassu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1588015195.16086.3.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=Silviu.Vlasceanu@huawei.com \
--cc=linux-integrity@vger.kernel.org \
--cc=mjg59@google.com \
--cc=roberto.sassu@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.