From: Stephen Smalley <firstname.lastname@example.org> To: Daniel Colascione <email@example.com> Cc: Tim Murray <firstname.lastname@example.org>, SElinux list <email@example.com>, LSM List <firstname.lastname@example.org>, Linux FS Devel <email@example.com>, linux-kernel <firstname.lastname@example.org>, email@example.com, Al Viro <firstname.lastname@example.org>, email@example.com, Nick Kralevich <firstname.lastname@example.org>, Lokesh Gidra <email@example.com>, Jeffrey Vander Stoep <firstname.lastname@example.org> Subject: Re: [PATCH 2/3] Teach SELinux about anonymous inodes Date: Fri, 14 Feb 2020 15:24:43 -0500 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 2/14/20 1:08 PM, Stephen Smalley wrote: > On 2/14/20 1:02 PM, Stephen Smalley wrote: >> It shouldn't fire for non-anon inodes because on a (non-anon) file >> creation, security_transition_sid() is passed the parent directory SID >> as the second argument and we only assign task SIDs to /proc/pid >> directories, which don't support (userspace) file creation anyway. >> >> However, in the absence of a matching type_transition rule, we'll end >> up defaulting to the task SID on the anon inode, and without a >> separate class we won't be able to distinguish it from a /proc/pid >> inode. So that might justify a separate anoninode or similar class. >> >> This however reminded me that for the context_inode case, we not only >> want to inherit the SID but also the sclass from the context_inode. >> That is so that anon inodes created via device node ioctls inherit the >> same SID/class pair as the device node and a single allowx rule can >> govern all ioctl commands on that device. > > At least that's the way our patch worked with the /dev/kvm example. > However, if we are introducing a separate anoninode class for the > type_transition case, maybe we should apply that to all anon inodes > regardless of how they are labeled (based on context_inode or > transition) and then we'd need to write two allowx rules, one for ioctls > on the original device node and one for those on anon inodes created > from it. Not sure how Android wants to handle that as the original > developer and primary user of SELinux ioctl whitelisting. I would tentatively argue for inheriting both sclass and SID from the context_inode for the sake of sane policy writing. In the userfaultfd case, that will still end up using the new SECCLASS_ANONINODE or whatever since the sclass will be initially set to that value for the transition SID case and then inherited on fork. But for /dev/kvm, it would be the class from the /dev/kvm inode, i.e. SECCLASS_CHR_FILE.
next prev parent reply index Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <email@example.com> 2020-02-14 3:26 ` [PATCH 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione 2020-02-14 3:26 ` [PATCH 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione 2020-02-14 3:26 ` [PATCH 2/3] Teach SELinux about anonymous inodes Daniel Colascione 2020-02-14 16:39 ` Stephen Smalley 2020-02-14 17:21 ` Daniel Colascione 2020-02-14 18:02 ` Stephen Smalley 2020-02-14 18:08 ` Stephen Smalley 2020-02-14 20:24 ` Stephen Smalley [this message] 2020-02-14 3:26 ` [PATCH 3/3] Wire UFFD up to SELinux Daniel Colascione
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/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 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ firstname.lastname@example.org public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git