From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Tianxing Zhang <anakinzhang96@gmail.com>, zohar@linux.ibm.com
Cc: linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] ima: check control characters in policy path
Date: Sat, 14 Aug 2021 08:47:53 -0400 [thread overview]
Message-ID: <b86ec24317e4a07901ee5d981d9bcf580c8fd2eb.camel@HansenPartnership.com> (raw)
In-Reply-To: <20210814081356.293-1-anakinzhang96@gmail.com>
On Sat, 2021-08-14 at 16:13 +0800, Tianxing Zhang wrote:
> Hi,
>
> IMA policy can be updated with /sys/kernel/security/ima/policy
> interface when CONFIG_IMA_WRITE_POLICY is set. However, kernel does
> not check the file path carefully. It only checks if the path has '/'
> prefix.
>
> When a policy file path contains control characters like '\r' or
> '\b', invalid error messages can be printed to overwrite system
> messages.
This doesn't sound like a good idea: filesystems accept control
characters in names, so the IMA file policy has to be able to specify
them. We can debate whether filesystems should do this, but while they
do IMA has to as well.
> For example:
>
> $ echo -e "/\rtest invalid path: ddddddddddddddddddddd" >
> /sys/kernel/security/ima/policy
> $ dmesg
> test invalid path: ddddddddddddddddddddd (-2)
>
> After adding this patch, we'll be able to throw out error message:
>
> $ echo -e "/\rtest invalid path: ddddddddddddddddddddd" >
> /sys/kernel/security/ima/policy
> -bash: echo: write error: Invalid argument
> $ dmesg
> [ 11.684004] ima: invalid path (control characters are not allowed)
> [ 11.684071] ima: policy update failed
>
> Any suggestions would be appreciated, thank you.
I don't quite understand what you think the problem is. Only root can
write IMA policies so no-one other than a legitimate administrator can
use bogus paths like the above. If the problem is producing a bogus
log message, we do have several IMA messages that print out
measured/appraised file names ... they would be vulnerable to this
since a generic user could have created them with control character
containg file names, and your proposed patch wouldn't fix that.
Wouldn't a better solution be to have a file name print that expands
the unprintable characters?
James
prev parent reply other threads:[~2021-08-14 12:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-14 8:13 Tianxing Zhang
2021-08-14 12:47 ` James Bottomley [this message]
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=b86ec24317e4a07901ee5d981d9bcf580c8fd2eb.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=anakinzhang96@gmail.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®