From: Stephen Smalley <email@example.com> To: Paul Moore <firstname.lastname@example.org> Cc: email@example.com Subject: Re: [RFC PATCH] selinux: add SELinux hooks for lockdown integrity and confidentiality Date: Thu, 7 Nov 2019 13:07:29 -0500 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAHC9VhSzoDnHK+fDXocShQALW32ctoOOC7GOeb_tEQsnmemail@example.com> On 11/7/19 12:48 PM, Paul Moore wrote: > On Thu, Oct 31, 2019 at 10:01 AM Stephen Smalley <firstname.lastname@example.org> wrote: > That is an interesting question: do we consider dmesg output to be > part of the stable kernel API? My hunch would be "no", as I've seen > things change quite a bit there over the years, but IANL (I Am Not > Linus). However, that said, logging a reason string via audit seems > like a good idea (especially since there is presently a many-to-one > mapping between reasons and the SELinux permission). Further, while > the audit field name is part of the kernel API, the value is much more > open. Ok, any preferences on the audit field name or should we just create one and cc linux-audit on the next RFC? lockdown_reason=? >> I also wasn't sure about the pr_warn() above. If we reach it, it is >> effectively a kernel bug. We could mirror what the lockdown module does >> in lockdown_is_locked_down(), i.e. use WARN() instead. Of course, the >> SELinux hook won't even be reached in this case if the lockdown module >> is enabled, but the lockdown module could be disabled so I guess we need >> to check it too. > > Since this seems security relevant, I wonder if we should be using SELINUX_ERR? The benefit of a WARN() is that it will give us a stack trace showing the offending caller in the kernel, which would be useful since it would be a buggy caller passing an invalid lockdown reason (LOCKDOWN_NONE or >= LOCKDOWN_CONFIDENTIALITY_MAX). pr_warn() or audit_log() won't give us that info. We could do both of course.
next prev parent reply index Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-30 13:16 Stephen Smalley 2019-10-30 15:29 ` Stephen Smalley 2019-10-31 9:47 ` Paul Moore 2019-10-31 9:59 ` Paul Moore 2019-10-31 14:01 ` Stephen Smalley 2019-11-07 17:48 ` Paul Moore 2019-11-07 18:07 ` Stephen Smalley [this message] 2019-11-08 18:38 ` Paul Moore
Reply instructions: You may reply publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
SELinux Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \ email@example.com public-inbox-index selinux Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.selinux AGPL code for this site: git clone https://public-inbox.org/public-inbox.git