From: Chris PeBenito <pebenito@ieee.org>
To: Russell Coker <russell@coker.com.au>, selinux-refpolicy@vger.kernel.org
Subject: Re: lockdown class
Date: Mon, 14 Dec 2020 10:13:25 -0500 [thread overview]
Message-ID: <4f69f374-3a67-55a2-3704-5cafd3719bf0@ieee.org> (raw)
In-Reply-To: <2911391.mirxchbQ87@liv>
On 12/11/20 2:01 AM, Russell Coker wrote:
> allow systemd_modules_load_t systemd_modules_load_t:lockdown integrity;
> allow udev_t udev_t:lockdown confidentiality;
>
> I've seen access that caused the above to be generated from audit2allow.
>
> /var/log/audit/audit.log.1:type=AVC msg=audit(1607515838.132:56): avc: denied
> { confidentiality } for pid=253 comm="systemd-udevd" lockdown_reason="use of
> tracefs" scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tclass=lockdown permissive=1
>
> Above is the only log entry I've got for that from my previous testing (I
> haven't been able to reproduce whatever it was that caused the
> systemd_modules_load_t to get that audited).
>
> https://www.paul-moore.com/blog/d/2020/03/linux_v56.html
>
> I've read the above blog post and I'm still not sure exactly how we are to use
> it. Do I allow this for systemd_modules_load_t because loading modules is an
> integrity issue? Do I allow it for udev_t because changing device names etc
> allows universal MITM attacks?
The SELinux check mirrors the lockdown LSM checks but the policy's granularity,
instead of the single granularity (system-wide)that lockdown LSM has.
If you had the lockdown LSM running too and set to the integrity level, the
systemd_modules_load_t would have been denied by lockdown instead of getting to
SELinux's check. The udev access to tracefs in would be allowed by the lockdown
LSM and go to SELinux's check.
Effectively you could reimplement the lockdown LSM in SELinux like this:
bool lockdown_integrity false;
bool lockdown_confidentiality false;
if (!lockdown_integrity && !lockdown_confidentiality) {
allow domain self:lockdown integrity;
}
if (!lockdown_confidentiality) {
allow domain self:lockdown confidentiality;
}
--
Chris PeBenito
prev parent reply other threads:[~2020-12-14 15:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 7:01 lockdown class Russell Coker
2020-12-14 15:13 ` Chris PeBenito [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=4f69f374-3a67-55a2-3704-5cafd3719bf0@ieee.org \
--to=pebenito@ieee.org \
--cc=russell@coker.com.au \
--cc=selinux-refpolicy@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).