From: Andy Lutomirski <luto@amacapital.net> To: Casey Schaufler <casey@schaufler-ca.com> Cc: Seth Forshee <seth.forshee@canonical.com>, "Eric W. Biederman" <ebiederm@xmission.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, SELinux-NSA <selinux@tycho.nsa.gov>, Serge Hallyn <serge.hallyn@canonical.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts Date: Thu, 16 Jul 2015 15:27:48 -0700 [thread overview] Message-ID: <CALCETrW6NpwY0CXNXWBcqx6JPyAqr6XP-BKexO1HFdpxnQUJrQ@mail.gmail.com> (raw) In-Reply-To: <55A8253E.3000407@schaufler-ca.com> On Thu, Jul 16, 2015 at 2:42 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > You want to provide a mechanism whereby an unprivileged user (Seth) > can mount a filesystem for his own use. You want full filesystem > semantics, but you're willing to accept restrictions on certain > filesystem features to avoid opening security holes. You are not > willing to accept restrictions that make the filesystem unusable, > such as making it read-only. > > I am going to present a suggestion. Feel free to correct my > assumptions and my reasoning. For simplicity let's use loop-back > mounting of a filesystem contained in a file as an example. The > principles should apply to newly created memory based filesystems > or disk partitions "owned" by Seth. > > Seth wants to mount a file (~seth/myfs) which contains an ext4 > filesystem. There is already a filesystem object, with security > attributes, that the system knows how to deal with. If Seth mounts > this as a filesystem he, and potentially other people, will be > able to access the content of this object without accessing the > object itself. > > seth$ mount --justforme -t ext4 ~seth/myfs /tmp/seth > seth$ chmod 777 /tmp/seth > seth$ ls -la /tmp/seth > drwxrwxrwx. 3 seth seth 260 Jul 16 12:59 . > drwxrwxrwxt 18 root root 4069 Jul 16 11:13 .. > seth$ > > Everything's fine at this point. Wilma is also using the system, > being the sort who likes to hide things in out of the way places > > wilma$ cp ~/scandals /tmp/seth > wilma$ chmod 600 /tmp/seth/scandals This is already impossible as described. Seth can only mount the filesystem in a private mount namespace inside a user namespace that he created. Wilma can't see it unless Seth passes an fd to Wilma and Wilma accepts and uses it. > > puts her list of scandals on the unsuspecting filesystem, and changes > the mode to ensure that no one can find out what went on after the > office party. > > Seth unmounts /tmp/seth. He looks in ~seth/myfs, finds out what really > happened at the office party, and the story goes from there. > > Wilma did everything correctly according to the system security policy, > but the system security policy did not protect her as advertised. The > system was tricked into behaving as if it was in control of the content > of the filesystem when in fact it was not. I would argue that, if Wilma writes to some place described by an fd and doesn't verify where she's writing to, then she has no expectation of privacy. After all, she could just *tell* Seth directly whatever she wants (assuming she can communicate with Seth in the first place). > > One way to fix this problem is for unprivileged mounts to recognize the > attributes of the object mounted and to propagate those attributes to all > the objects they present. All files on /tmp/seth would be owned by seth > and protected by the mode bits, ACL and LSM requirements of ~/seth/myfs. This is impossible to enforce, because Seth could use FUSE instead of ext4. > opening a file on /tmp/seth would require the same permissions as opening > the file containing the mounted filesystem. These attributes would have to > be immutable, or at least demonstrably more restrictive (chmod might be > allowed in some cases, but chown would never be) when changed. I don't see > how a user other than seth could create a new file, as you'd either have > a magical change in ownership or a false sense of security. This would be a very harsh restriction. Seth might legitimately want to give a user access to a file on backing store he owns without giving that user access to the backing store. Root on a normal system does that all the time. > If you can mount a filesystem such that the labels are ignored you > are effectively specifying that the Smack label on the files be > determined by the defaulting rules. With CAP_MAC_ADMIN that's fine. > Without it, it's not. Can you explain what the threat model is here? I don't see what it is that you're trying to prevent. >> Your point is taken about my less-than-expert opinion about the other >> security modules. We should at minimum get acks from the maintainers of >> those modules that unprivileged mounts will not compromise MAC. > > I am the Smack maintainer. Unprivileged mounts as you have > described them compromise MAC. They compromise DAC, too. > How do they compromise DAC? --Andy
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net> To: Casey Schaufler <casey@schaufler-ca.com> Cc: Serge Hallyn <serge.hallyn@canonical.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Seth Forshee <seth.forshee@canonical.com>, LSM List <linux-security-module@vger.kernel.org>, SELinux-NSA <selinux@tycho.nsa.gov>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk> Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts Date: Thu, 16 Jul 2015 15:27:48 -0700 [thread overview] Message-ID: <CALCETrW6NpwY0CXNXWBcqx6JPyAqr6XP-BKexO1HFdpxnQUJrQ@mail.gmail.com> (raw) In-Reply-To: <55A8253E.3000407@schaufler-ca.com> On Thu, Jul 16, 2015 at 2:42 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > You want to provide a mechanism whereby an unprivileged user (Seth) > can mount a filesystem for his own use. You want full filesystem > semantics, but you're willing to accept restrictions on certain > filesystem features to avoid opening security holes. You are not > willing to accept restrictions that make the filesystem unusable, > such as making it read-only. > > I am going to present a suggestion. Feel free to correct my > assumptions and my reasoning. For simplicity let's use loop-back > mounting of a filesystem contained in a file as an example. The > principles should apply to newly created memory based filesystems > or disk partitions "owned" by Seth. > > Seth wants to mount a file (~seth/myfs) which contains an ext4 > filesystem. There is already a filesystem object, with security > attributes, that the system knows how to deal with. If Seth mounts > this as a filesystem he, and potentially other people, will be > able to access the content of this object without accessing the > object itself. > > seth$ mount --justforme -t ext4 ~seth/myfs /tmp/seth > seth$ chmod 777 /tmp/seth > seth$ ls -la /tmp/seth > drwxrwxrwx. 3 seth seth 260 Jul 16 12:59 . > drwxrwxrwxt 18 root root 4069 Jul 16 11:13 .. > seth$ > > Everything's fine at this point. Wilma is also using the system, > being the sort who likes to hide things in out of the way places > > wilma$ cp ~/scandals /tmp/seth > wilma$ chmod 600 /tmp/seth/scandals This is already impossible as described. Seth can only mount the filesystem in a private mount namespace inside a user namespace that he created. Wilma can't see it unless Seth passes an fd to Wilma and Wilma accepts and uses it. > > puts her list of scandals on the unsuspecting filesystem, and changes > the mode to ensure that no one can find out what went on after the > office party. > > Seth unmounts /tmp/seth. He looks in ~seth/myfs, finds out what really > happened at the office party, and the story goes from there. > > Wilma did everything correctly according to the system security policy, > but the system security policy did not protect her as advertised. The > system was tricked into behaving as if it was in control of the content > of the filesystem when in fact it was not. I would argue that, if Wilma writes to some place described by an fd and doesn't verify where she's writing to, then she has no expectation of privacy. After all, she could just *tell* Seth directly whatever she wants (assuming she can communicate with Seth in the first place). > > One way to fix this problem is for unprivileged mounts to recognize the > attributes of the object mounted and to propagate those attributes to all > the objects they present. All files on /tmp/seth would be owned by seth > and protected by the mode bits, ACL and LSM requirements of ~/seth/myfs. This is impossible to enforce, because Seth could use FUSE instead of ext4. > opening a file on /tmp/seth would require the same permissions as opening > the file containing the mounted filesystem. These attributes would have to > be immutable, or at least demonstrably more restrictive (chmod might be > allowed in some cases, but chown would never be) when changed. I don't see > how a user other than seth could create a new file, as you'd either have > a magical change in ownership or a false sense of security. This would be a very harsh restriction. Seth might legitimately want to give a user access to a file on backing store he owns without giving that user access to the backing store. Root on a normal system does that all the time. > If you can mount a filesystem such that the labels are ignored you > are effectively specifying that the Smack label on the files be > determined by the defaulting rules. With CAP_MAC_ADMIN that's fine. > Without it, it's not. Can you explain what the threat model is here? I don't see what it is that you're trying to prevent. >> Your point is taken about my less-than-expert opinion about the other >> security modules. We should at minimum get acks from the maintainers of >> those modules that unprivileged mounts will not compromise MAC. > > I am the Smack maintainer. Unprivileged mounts as you have > described them compromise MAC. They compromise DAC, too. > How do they compromise DAC? --Andy
next prev parent reply other threads:[~2015-07-16 22:28 UTC|newest] Thread overview: 232+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-07-15 19:46 [PATCH 0/7] Initial support for user namespace owned mounts Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-15 19:46 ` [PATCH 1/7] fs: Add user namesapace member to struct super_block Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-16 2:47 ` Eric W. Biederman 2015-07-16 2:47 ` Eric W. Biederman 2015-08-05 21:03 ` Seth Forshee 2015-08-05 21:03 ` Seth Forshee 2015-08-05 21:19 ` Eric W. Biederman 2015-08-05 21:19 ` Eric W. Biederman 2015-08-06 14:20 ` Seth Forshee 2015-08-06 14:20 ` Seth Forshee 2015-08-06 14:51 ` Stephen Smalley 2015-08-06 14:51 ` Stephen Smalley 2015-08-06 15:44 ` Seth Forshee 2015-08-06 15:44 ` Seth Forshee 2015-08-06 16:11 ` Stephen Smalley 2015-08-06 16:11 ` Stephen Smalley 2015-08-07 14:16 ` Seth Forshee 2015-08-07 14:16 ` Seth Forshee 2015-08-07 14:32 ` Seth Forshee 2015-08-07 14:32 ` Seth Forshee 2015-08-07 18:35 ` Casey Schaufler 2015-08-07 18:35 ` Casey Schaufler 2015-08-07 18:57 ` Seth Forshee 2015-08-07 18:57 ` Seth Forshee 2015-07-15 19:46 ` [PATCH 2/7] userns: Simpilify MNT_NODEV handling Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-15 19:46 ` [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-15 21:48 ` Serge E. Hallyn 2015-07-15 21:48 ` Serge E. Hallyn 2015-07-15 21:50 ` Andy Lutomirski 2015-07-15 21:50 ` Andy Lutomirski 2015-07-15 22:35 ` Eric W. Biederman 2015-07-15 22:35 ` Eric W. Biederman 2015-07-16 1:14 ` Seth Forshee 2015-07-16 1:14 ` Seth Forshee 2015-07-16 1:23 ` Andy Lutomirski 2015-07-16 1:23 ` Andy Lutomirski 2015-07-16 13:06 ` Seth Forshee 2015-07-16 13:06 ` Seth Forshee 2015-07-16 1:19 ` Andy Lutomirski 2015-07-16 1:19 ` Andy Lutomirski 2015-07-16 4:23 ` Eric W. Biederman 2015-07-16 4:23 ` Eric W. Biederman 2015-07-16 4:49 ` Andy Lutomirski 2015-07-16 4:49 ` Andy Lutomirski 2015-07-16 5:04 ` Eric W. Biederman 2015-07-16 5:04 ` Eric W. Biederman 2015-07-16 5:15 ` Andy Lutomirski 2015-07-16 5:15 ` Andy Lutomirski 2015-07-16 5:44 ` Eric W. Biederman 2015-07-16 5:44 ` Eric W. Biederman 2015-07-16 13:13 ` Seth Forshee 2015-07-16 13:13 ` Seth Forshee 2015-07-17 0:43 ` Eric W. Biederman 2015-07-17 0:43 ` Eric W. Biederman 2015-07-29 16:04 ` Serge E. Hallyn 2015-07-29 16:04 ` Serge E. Hallyn 2015-07-29 16:18 ` Serge E. Hallyn 2015-07-29 16:18 ` Serge E. Hallyn 2015-07-15 19:46 ` [PATCH 4/7] fs: Treat foreign mounts as nosuid Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-17 6:46 ` Nikolay Borisov 2015-07-17 6:46 ` Nikolay Borisov 2015-07-15 19:46 ` [PATCH 5/7] security: Restrict security attribute updates for userns mounts Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-15 19:46 ` [PATCH 6/7] selinux: Ignore security labels on user namespace mounts Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-16 13:23 ` Stephen Smalley 2015-07-22 16:02 ` Stephen Smalley 2015-07-22 16:14 ` Seth Forshee 2015-07-22 16:14 ` Seth Forshee 2015-07-22 20:25 ` Stephen Smalley 2015-07-22 20:25 ` Stephen Smalley 2015-07-22 20:40 ` Stephen Smalley 2015-07-22 20:40 ` Stephen Smalley 2015-07-23 13:57 ` Stephen Smalley 2015-07-23 13:57 ` Stephen Smalley 2015-07-23 14:39 ` Seth Forshee 2015-07-23 14:39 ` Seth Forshee 2015-07-23 15:36 ` Stephen Smalley 2015-07-23 15:36 ` Stephen Smalley 2015-07-23 16:23 ` Seth Forshee 2015-07-23 16:23 ` Seth Forshee 2015-07-24 15:11 ` Seth Forshee 2015-07-24 15:11 ` Seth Forshee 2015-07-30 15:57 ` Stephen Smalley 2015-07-30 15:57 ` Stephen Smalley 2015-07-30 16:24 ` Seth Forshee 2015-07-30 16:24 ` Seth Forshee 2015-07-15 19:46 ` [PATCH 7/7] smack: Don't use security labels for " Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-15 20:43 ` Casey Schaufler 2015-07-15 20:43 ` Casey Schaufler 2015-07-15 20:36 ` [PATCH 0/7] Initial support for user namespace owned mounts Casey Schaufler 2015-07-15 20:36 ` Casey Schaufler 2015-07-15 21:06 ` Eric W. Biederman 2015-07-15 21:06 ` Eric W. Biederman 2015-07-15 21:48 ` Seth Forshee 2015-07-15 21:48 ` Seth Forshee 2015-07-15 22:28 ` Eric W. Biederman 2015-07-15 22:28 ` Eric W. Biederman 2015-07-16 1:05 ` Andy Lutomirski 2015-07-16 1:05 ` Andy Lutomirski 2015-07-16 2:20 ` Eric W. Biederman 2015-07-16 2:20 ` Eric W. Biederman 2015-07-16 13:12 ` Stephen Smalley 2015-07-16 13:12 ` Stephen Smalley 2015-07-15 23:04 ` Casey Schaufler 2015-07-15 23:04 ` Casey Schaufler 2015-07-15 22:39 ` Casey Schaufler 2015-07-15 22:39 ` Casey Schaufler 2015-07-16 1:08 ` Andy Lutomirski 2015-07-16 1:08 ` Andy Lutomirski 2015-07-16 2:54 ` Casey Schaufler 2015-07-16 2:54 ` Casey Schaufler 2015-07-16 4:47 ` Eric W. Biederman 2015-07-16 4:47 ` Eric W. Biederman 2015-07-17 0:09 ` Dave Chinner 2015-07-17 0:09 ` Dave Chinner 2015-07-17 0:42 ` Eric W. Biederman 2015-07-17 0:42 ` Eric W. Biederman 2015-07-17 2:47 ` Dave Chinner 2015-07-17 2:47 ` Dave Chinner 2015-07-21 17:37 ` J. Bruce Fields 2015-07-21 17:37 ` J. Bruce Fields 2015-07-22 7:56 ` Dave Chinner 2015-07-22 7:56 ` Dave Chinner 2015-07-22 14:09 ` J. Bruce Fields 2015-07-22 14:09 ` J. Bruce Fields 2015-07-22 16:52 ` Austin S Hemmelgarn 2015-07-22 16:52 ` Austin S Hemmelgarn 2015-07-22 17:41 ` J. Bruce Fields 2015-07-22 17:41 ` J. Bruce Fields 2015-07-23 1:51 ` Dave Chinner 2015-07-23 1:51 ` Dave Chinner 2015-07-23 13:19 ` J. Bruce Fields 2015-07-23 13:19 ` J. Bruce Fields 2015-07-23 23:48 ` Dave Chinner 2015-07-23 23:48 ` Dave Chinner 2015-07-18 0:07 ` Serge E. Hallyn 2015-07-18 0:07 ` Serge E. Hallyn 2015-07-20 17:54 ` Colin Walters 2015-07-20 17:54 ` Colin Walters 2015-07-16 11:16 ` Lukasz Pawelczyk 2015-07-16 11:16 ` Lukasz Pawelczyk 2015-07-17 0:10 ` Eric W. Biederman 2015-07-17 0:10 ` Eric W. Biederman 2015-07-17 10:13 ` Lukasz Pawelczyk 2015-07-17 10:13 ` Lukasz Pawelczyk 2015-07-16 3:15 ` Eric W. Biederman 2015-07-16 3:15 ` Eric W. Biederman 2015-07-16 13:59 ` Seth Forshee 2015-07-16 13:59 ` Seth Forshee 2015-07-16 15:09 ` Casey Schaufler 2015-07-16 15:09 ` Casey Schaufler 2015-07-16 18:57 ` Seth Forshee 2015-07-16 18:57 ` Seth Forshee 2015-07-16 21:42 ` Casey Schaufler 2015-07-16 21:42 ` Casey Schaufler 2015-07-16 22:27 ` Andy Lutomirski [this message] 2015-07-16 22:27 ` Andy Lutomirski 2015-07-16 23:08 ` Casey Schaufler 2015-07-16 23:08 ` Casey Schaufler 2015-07-16 23:29 ` Andy Lutomirski 2015-07-16 23:29 ` Andy Lutomirski 2015-07-17 0:45 ` Casey Schaufler 2015-07-17 0:45 ` Casey Schaufler 2015-07-17 0:59 ` Andy Lutomirski 2015-07-17 0:59 ` Andy Lutomirski 2015-07-17 14:28 ` Serge E. Hallyn 2015-07-17 14:28 ` Serge E. Hallyn 2015-07-17 14:56 ` Seth Forshee 2015-07-17 14:56 ` Seth Forshee 2015-07-21 20:35 ` Seth Forshee 2015-07-21 20:35 ` Seth Forshee 2015-07-22 1:52 ` Casey Schaufler 2015-07-22 1:52 ` Casey Schaufler 2015-07-22 15:56 ` Seth Forshee 2015-07-22 15:56 ` Seth Forshee 2015-07-22 18:10 ` Casey Schaufler 2015-07-22 18:10 ` Casey Schaufler 2015-07-22 19:32 ` Seth Forshee 2015-07-22 19:32 ` Seth Forshee 2015-07-23 0:05 ` Casey Schaufler 2015-07-23 0:05 ` Casey Schaufler 2015-07-23 0:15 ` Eric W. Biederman 2015-07-23 0:15 ` Eric W. Biederman 2015-07-23 5:15 ` Seth Forshee 2015-07-23 5:15 ` Seth Forshee 2015-07-23 21:48 ` Casey Schaufler 2015-07-23 21:48 ` Casey Schaufler 2015-07-28 20:40 ` Seth Forshee 2015-07-28 20:40 ` Seth Forshee 2015-07-30 16:18 ` Casey Schaufler 2015-07-30 16:18 ` Casey Schaufler 2015-07-30 17:05 ` Eric W. Biederman 2015-07-30 17:05 ` Eric W. Biederman 2015-07-30 17:25 ` Seth Forshee 2015-07-30 17:25 ` Seth Forshee 2015-07-30 17:33 ` Eric W. Biederman 2015-07-30 17:33 ` Eric W. Biederman 2015-07-17 13:21 ` Seth Forshee 2015-07-17 13:21 ` Seth Forshee 2015-07-17 17:14 ` Casey Schaufler 2015-07-17 17:14 ` Casey Schaufler 2015-07-16 15:59 ` Seth Forshee 2015-07-16 15:59 ` Seth Forshee 2015-07-30 4:24 Amir Goldstein 2015-07-30 4:24 ` Amir Goldstein 2015-07-30 13:55 ` Seth Forshee 2015-07-30 13:55 ` Seth Forshee 2015-07-30 14:47 ` Amir Goldstein 2015-07-30 14:47 ` Amir Goldstein 2015-07-30 15:33 ` Casey Schaufler 2015-07-30 15:33 ` Casey Schaufler 2015-07-30 15:52 ` Colin Walters 2015-07-30 15:52 ` Colin Walters 2015-07-30 16:15 ` Eric W. Biederman 2015-07-30 16:15 ` Eric W. Biederman 2015-07-30 13:57 ` Serge Hallyn 2015-07-30 13:57 ` Serge Hallyn 2015-07-30 15:09 ` Amir Goldstein 2015-07-30 15:09 ` Amir Goldstein 2015-07-31 8:11 Amir Goldstein 2015-07-31 8:11 ` Amir Goldstein 2015-07-31 19:56 ` Casey Schaufler 2015-07-31 19:56 ` Casey Schaufler 2015-08-01 17:01 ` Amir Goldstein 2015-08-01 17:01 ` Amir Goldstein
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=CALCETrW6NpwY0CXNXWBcqx6JPyAqr6XP-BKexO1HFdpxnQUJrQ@mail.gmail.com \ --to=luto@amacapital.net \ --cc=casey@schaufler-ca.com \ --cc=ebiederm@xmission.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=selinux@tycho.nsa.gov \ --cc=serge.hallyn@canonical.com \ --cc=seth.forshee@canonical.com \ --cc=viro@zeniv.linux.org.uk \ /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.