From: Stephen Smalley <sds@tycho.nsa.gov> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>, tglx@linutronix.de, linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, James Morris <jmorris@namei.org>, Eric Paris <eparis@parisplace.org> Subject: Re: [PATCH 2/2] sysctl: Restore the selinux path based label lookup for sysctls. Date: Thu, 08 Feb 2007 13:13:24 -0500 [thread overview] Message-ID: <1170958404.11912.313.camel@moss-spartans.epoch.ncsc.mil> (raw) In-Reply-To: <m14ppwa64j.fsf@ebiederm.dsl.xmission.com> On Thu, 2007-02-08 at 10:53 -0700, Eric W. Biederman wrote: > Stephen Smalley <sds@tycho.nsa.gov> writes: > > > > > Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't > > truly private to the fs, so we can run into them in a variety of > > security hooks beyond just the inode hooks, such as > > security_file_permission (when reading and writing them via the vfs > > helpers), security_sb_mount (when mounting other filesystems on > > directories in proc like binfmt_misc), and deeper within the security > > module itself (as in flush_unauthorized_files upon inheritance across > > execve). So I think we have to add an IS_PRIVATE() guard within > > SELinux, as below. Note however that the use of the private flag here > > could be confusing, as these inodes are _not_ private to the fs, are > > exposed to userspace, and security modules must implement the sysctl > > hook to get any access control over them. > > Agreed, the naming is confusing, and using private here doesn't quite > feel right. > > A practical question is: Will we ever encounter these inodes > in the inode_init() path from superblock_init? Possibly, during setup upon initial policy load (initiated by /sbin/init these days) from selinux_complete_init, as early userspace may have already been accessing them. > If all of the accesses > that we care about go through inode_doinit_with_dentry we can just > walk the dcache to get the names, and that should work for the normal > proc case as well. Walking the proc_dir_entry tree (or the ctl_table tree) is preferable as it is a stable, user-immutable representation. Also avoids taking the dcache lock. > A somewhat related question: How do you handle security labels for > sysfs? No fine grained security yet. Right, they are all mapped to a single label presently. I was thinking of handling that from userspace after introducing a setxattr handler for sysfs and a way to preserve the SID on the entry (likely caching it in the sysfs_dirent and propagating that to the inode when the inode is populated from the sysfs_dirent). Then early userspace could walk sysfs and apply finer-grained labeling from a configuration. > If it doesn't look easy to solve this another way I will certainly > go with marking the inodes private. -- Stephen Smalley National Security Agency
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Smalley <sds@tycho.nsa.gov> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>, tglx@linutronix.de, linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, James Morris <jmorris@namei.org>, Eric Paris <eparis@parisplace.org> Subject: Re: [PATCH 2/2] sysctl: Restore the selinux path based label lookup for sysctls. Date: Thu, 08 Feb 2007 13:13:24 -0500 [thread overview] Message-ID: <1170958404.11912.313.camel@moss-spartans.epoch.ncsc.mil> (raw) In-Reply-To: <m14ppwa64j.fsf@ebiederm.dsl.xmission.com> On Thu, 2007-02-08 at 10:53 -0700, Eric W. Biederman wrote: > Stephen Smalley <sds@tycho.nsa.gov> writes: > > > > > Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't > > truly private to the fs, so we can run into them in a variety of > > security hooks beyond just the inode hooks, such as > > security_file_permission (when reading and writing them via the vfs > > helpers), security_sb_mount (when mounting other filesystems on > > directories in proc like binfmt_misc), and deeper within the security > > module itself (as in flush_unauthorized_files upon inheritance across > > execve). So I think we have to add an IS_PRIVATE() guard within > > SELinux, as below. Note however that the use of the private flag here > > could be confusing, as these inodes are _not_ private to the fs, are > > exposed to userspace, and security modules must implement the sysctl > > hook to get any access control over them. > > Agreed, the naming is confusing, and using private here doesn't quite > feel right. > > A practical question is: Will we ever encounter these inodes > in the inode_init() path from superblock_init? Possibly, during setup upon initial policy load (initiated by /sbin/init these days) from selinux_complete_init, as early userspace may have already been accessing them. > If all of the accesses > that we care about go through inode_doinit_with_dentry we can just > walk the dcache to get the names, and that should work for the normal > proc case as well. Walking the proc_dir_entry tree (or the ctl_table tree) is preferable as it is a stable, user-immutable representation. Also avoids taking the dcache lock. > A somewhat related question: How do you handle security labels for > sysfs? No fine grained security yet. Right, they are all mapped to a single label presently. I was thinking of handling that from userspace after introducing a setxattr handler for sysfs and a way to preserve the SID on the entry (likely caching it in the sysfs_dirent and propagating that to the inode when the inode is populated from the sysfs_dirent). Then early userspace could walk sysfs and apply finer-grained labeling from a configuration. > If it doesn't look easy to solve this another way I will certainly > go with marking the inodes private. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2007-02-08 18:18 UTC|newest] Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-01-28 1:05 + clocksource-add-verification-watchdog-helper-fix-3.patch added to -mm tree akpm [not found] ` <20070127172410.2b041952.akpm@osdl.org> [not found] ` <1169972718.17469.164.camel@localhost.localdomain> [not found] ` <20070128003549.2ca38dc8.akpm@osdl.org> [not found] ` <20070128093358.GA2071@elte.hu> [not found] ` <20070128095712.GA6485@elte.hu> [not found] ` <20070128100627.GA8416@elte.hu> [not found] ` <20070128104548.a835d859.akpm@osdl.org> 2007-01-28 19:21 ` [PATCH] sysctl selinux: Don't look at table->de Eric W. Biederman 2007-01-28 19:21 ` Eric W. Biederman 2007-01-29 13:04 ` Stephen Smalley 2007-01-29 13:04 ` Stephen Smalley 2007-01-29 15:23 ` James Morris 2007-01-29 15:23 ` James Morris 2007-01-29 17:55 ` Eric W. Biederman 2007-01-29 17:55 ` Eric W. Biederman 2007-01-29 19:26 ` Stephen Smalley 2007-01-29 19:26 ` Stephen Smalley 2007-01-29 17:43 ` Eric W. Biederman 2007-01-29 17:43 ` Eric W. Biederman 2007-01-29 18:43 ` Stephen Smalley 2007-01-29 18:43 ` Stephen Smalley 2007-01-29 19:08 ` Casey Schaufler 2007-01-29 19:08 ` Casey Schaufler 2007-01-29 20:07 ` Stephen Smalley 2007-01-29 20:07 ` Stephen Smalley 2007-01-30 10:25 ` Christoph Hellwig 2007-01-30 17:19 ` Casey Schaufler 2007-01-30 17:19 ` Casey Schaufler 2007-01-29 19:16 ` Eric W. Biederman 2007-01-29 19:16 ` Eric W. Biederman 2007-01-29 23:28 ` Russell Coker 2007-01-29 23:28 ` Russell Coker 2007-02-06 21:16 ` [PATCH 1/2] sysctl: Add a parent entry to ctl_table and set the parent entry Eric W. Biederman 2007-02-06 21:16 ` Eric W. Biederman 2007-02-06 21:21 ` [PATCH 2/2] sysctl: Restore the selinux path based label lookup for sysctls Eric W. Biederman 2007-02-06 21:21 ` Eric W. Biederman 2007-02-07 18:24 ` Stephen Smalley 2007-02-07 18:24 ` Stephen Smalley 2007-02-07 21:12 ` Stephen Smalley 2007-02-07 21:12 ` Stephen Smalley 2007-02-07 21:54 ` Stephen Smalley 2007-02-07 21:54 ` Stephen Smalley 2007-02-07 22:21 ` Eric W. Biederman 2007-02-07 22:21 ` Eric W. Biederman 2007-02-08 15:07 ` Stephen Smalley 2007-02-08 15:07 ` Stephen Smalley 2007-02-08 1:57 ` Eric W. Biederman 2007-02-08 1:57 ` Eric W. Biederman 2007-02-08 15:01 ` Stephen Smalley 2007-02-08 15:01 ` Stephen Smalley 2007-02-08 17:53 ` Eric W. Biederman 2007-02-08 17:53 ` Eric W. Biederman 2007-02-08 18:13 ` Stephen Smalley [this message] 2007-02-08 18:13 ` Stephen Smalley 2007-02-08 22:17 ` Eric W. Biederman 2007-02-08 22:17 ` Eric W. Biederman 2007-02-08 22:51 ` [PATCH 0/5] sysctl cleanup selinux fixes Eric W. Biederman 2007-02-08 22:51 ` Eric W. Biederman 2007-02-08 22:53 ` [PATCH 1/5] sysctl: Remove declaration of nonexistent sysctl_init() Eric W. Biederman 2007-02-08 22:53 ` Eric W. Biederman 2007-02-08 22:54 ` [PATCH 2/5] sysctl: Set the parent field in the root sysctl table Eric W. Biederman 2007-02-08 22:54 ` Eric W. Biederman 2007-02-08 22:55 ` [PATCH 3/5] sysctl: Fix the selinux_sysctl_get_sid Eric W. Biederman 2007-02-08 22:55 ` Eric W. Biederman 2007-02-08 23:02 ` [PATCH 4/5] selinux: Enhance selinux to always ignore private inodes Eric W. Biederman 2007-02-08 23:02 ` Eric W. Biederman 2007-02-08 23:04 ` [PATCH 5/5] sysctl: Hide the sysctl proc inodes from selinux Eric W. Biederman 2007-02-08 23:04 ` Eric W. Biederman 2007-02-09 12:26 ` [PATCH 4/5] selinux: Enhance selinux to always ignore private inodes Stephen Smalley 2007-02-09 12:26 ` Stephen Smalley 2007-02-09 12:24 ` [PATCH 3/5] sysctl: Fix the selinux_sysctl_get_sid Stephen Smalley 2007-02-09 12:24 ` Stephen Smalley 2007-02-09 11:05 ` [PATCH 0/5] sysctl cleanup selinux fixes Andrew Morton 2007-02-09 18:09 ` Eric W. Biederman 2007-02-09 18:09 ` Eric W. Biederman
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=1170958404.11912.313.camel@moss-spartans.epoch.ncsc.mil \ --to=sds@tycho.nsa.gov \ --cc=akpm@osdl.org \ --cc=ebiederm@xmission.com \ --cc=eparis@parisplace.org \ --cc=jmorris@namei.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@elte.hu \ --cc=selinux@tycho.nsa.gov \ --cc=tglx@linutronix.de \ /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: linkBe 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.