Re: [PATCH v3] capabilities.7, prctl.2: Document ambient capabilities

Hi Andy, I have applied your patch (below). Thanks for writing it. But I have a question or two and a request. === In the capabilities(7) page tehre is the longstanding text: An application can use the following call to lock itself, and all of its descendants, into an

Re: [PATCH 17/19] fuse: Support fuse filesystems outside of init_user_ns

On Wed, Dec 02, 2015 at 09:40:17AM -0600, Seth Forshee wrote: > @@ -155,11 +155,22 @@ static ino_t fuse_squash_ino(u64 ino64) > return ino; > } > > -void fuse_change_attributes_common(struct inode *inode, struct fuse_attr > *attr, > -u64 attr_valid) > +int

Re: [patch] Smack: harmless underflow in smk_set_cipso()

On Thu, Dec 03, 2015 at 02:23:22PM -0800, Casey Schaufler wrote: > On 11/3/2015 2:15 PM, Dan Carpenter wrote: > >Also checkpatch complains that we should use kstrtouint() instead of > >sscanf here. > > > >Signed-off-by: Dan Carpenter > > This no longer parses cipso

Re: [PATCH 09/19] fs: Refuse uid/gid changes which don't map into s_user_ns

On Wed, Dec 02, 2015 at 09:40:09AM -0600, Seth Forshee wrote: > Add checks to inode_change_ok to verify that uid and gid changes > will map into the superblock's user namespace. If they do not > fail with -EOVERFLOW. This cannot be overriden with ATTR_FORCE. > > Signed-off-by: Seth Forshee

Re: [PATCH 09/19] fs: Refuse uid/gid changes which don't map into s_user_ns

On Fri, Dec 04, 2015 at 11:27:38AM -0600, Serge E. Hallyn wrote: > On Wed, Dec 02, 2015 at 09:40:09AM -0600, Seth Forshee wrote: > > Add checks to inode_change_ok to verify that uid and gid changes > > will map into the superblock's user namespace. If they do not > > fail with -EOVERFLOW. This

Re: [PATCH 01/19] block_dev: Support checking inode permissions in lookup_bdev()

On Wed, Dec 02, 2015 at 09:40:01AM -0600, Seth Forshee wrote: > When looking up a block device by path no permission check is > done to verify that the user has access to the block device inode > at the specified path. In some cases it may be necessary to > check permissions towards the inode,

Re: [PATCH 07/19] fs: Check for invalid i_uid in may_follow_link()

On Wed, Dec 02, 2015 at 09:40:07AM -0600, Seth Forshee wrote: > Filesystem uids which don't map into a user namespace may result > in inode->i_uid being INVALID_UID. A symlink and its parent > could have different owners in the filesystem can both get > mapped to INVALID_UID, which may result in

Re: [PATCH 08/19] cred: Reject inodes with invalid ids in set_create_file_as()

On Wed, Dec 02, 2015 at 09:40:08AM -0600, Seth Forshee wrote: > Using INVALID_[UG]ID for the LSM file creation context doesn't > make sense, so return an error if the inode passed to > set_create_file_as() has an invalid id. > > Signed-off-by: Seth Forshee Acked-by:

Re: [PATCH 05/19] userns: Replace in_userns with current_in_userns

On Wed, Dec 02, 2015 at 09:40:05AM -0600, Seth Forshee wrote: > All current callers of in_userns pass current_user_ns as the > first argument. Simplify by replacing in_userns with > current_in_userns which checks whether current_user_ns is in the > namespace supplied as an argument. > >

Re: [PATCH 03/19] fs: Treat foreign mounts as nosuid

On Wed, Dec 02, 2015 at 09:40:03AM -0600, Seth Forshee wrote: > From: Andy Lutomirski > > If a process gets access to a mount from a different user > namespace, that process should not be able to take advantage of > setuid files or selinux entrypoints from that filesystem.

Re: [PATCH 02/19] block_dev: Check permissions towards block device inode when mounting

On Wed, Dec 02, 2015 at 09:40:02AM -0600, Seth Forshee wrote: > Unprivileged users should not be able to mount block devices when > they lack sufficient privileges towards the block device inode. > Update blkdev_get_by_path() to validate that the user has the > required access to the inode at the

Re: [PATCH 09/19] fs: Refuse uid/gid changes which don't map into s_user_ns

Quoting Seth Forshee (seth.fors...@canonical.com): > On Fri, Dec 04, 2015 at 11:27:38AM -0600, Serge E. Hallyn wrote: > > On Wed, Dec 02, 2015 at 09:40:09AM -0600, Seth Forshee wrote: > > > Add checks to inode_change_ok to verify that uid and gid changes > > > will map into the superblock's user

Re: [PATCH 17/19] fuse: Support fuse filesystems outside of init_user_ns

Quoting Seth Forshee (seth.fors...@canonical.com): > Update fuse to translate uids and gids to/from the user namspace > of the process servicing requests on /dev/fuse. Any ids which do > not map into the namespace will result in errors. inodes will > also be marked bad when unmappable ids are

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

Heh, I was looking over http://www.gossamer-threads.com/lists/linux/kernel/103611 a little while ago :) The same question was asked 16 years ago. Apparently the answer then was that it was easier than fixing the code. Quoting Theodore Ts'o (ty...@mit.edu): > The fact that we need CAP_SYS_RAIO

Re: [PATCH 18/19] fuse: Restrict allow_other to the superblock's namespace or a descendant

Quoting Seth Forshee (seth.fors...@canonical.com): > Unprivileged users are normally restricted from mounting with the > allow_other option by system policy, but this could be bypassed > for a mount done with user namespace root permissions. In such > cases allow_other should not allow users

Re: [PATCH 17/19] fuse: Support fuse filesystems outside of init_user_ns

On Fri, Dec 04, 2015 at 02:03:55PM -0600, Serge E. Hallyn wrote: > Quoting Seth Forshee (seth.fors...@canonical.com): > > Update fuse to translate uids and gids to/from the user namspace > > of the process servicing requests on /dev/fuse. Any ids which do > > not map into the namespace will result

Re: [PATCH RFC] Introduce new security.nscapability xattr

Quoting Eric W. Biederman (ebied...@xmission.com): > "Serge E. Hallyn" writes: > > > A common way for daemons to run with minimal privilege is to start as root, > > perhaps setuid-root, choose a desired capability set, set PR_SET_KEEPCAPS, > > then change uid to

Re: [PATCH 18/19] fuse: Restrict allow_other to the superblock's namespace or a descendant

On Fri, Dec 04, 2015 at 02:05:41PM -0600, Serge E. Hallyn wrote: > Quoting Seth Forshee (seth.fors...@canonical.com): > > Unprivileged users are normally restricted from mounting with the > > allow_other option by system policy, but this could be bypassed > > for a mount done with user namespace

[PATCH v1 1/1] selinux: use absolute path to include directory

Compiler warns us a lot that it can't find include folder because it's provided in relative form. CC security/selinux/netlabel.o cc1: warning: security/selinux/include: No such file or directory [-Wmissing-include-dirs] cc1: warning: security/selinux/include: No such file or directory

Re: [PATCH 15/19] capabilities: Allow privileged user in s_user_ns to set file caps

On Fri, Dec 04, 2015 at 02:36:27PM -0600, Seth Forshee wrote: > On Fri, Dec 04, 2015 at 01:42:06PM -0600, Serge E. Hallyn wrote: > > Quoting Seth Forshee (seth.fors...@canonical.com): > > > A privileged user in a super block's s_user_ns is privileged > > > towards that file system and thus should

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

On Fri, Dec 04, 2015 at 02:45:32PM -0600, Seth Forshee wrote: > On Fri, Dec 04, 2015 at 02:07:36PM -0600, Serge E. Hallyn wrote: > > Heh, I was looking over > > http://www.gossamer-threads.com/lists/linux/kernel/103611 > > a little while ago :) The same question was asked 16 years ago.

Re: [PATCH 15/19] capabilities: Allow privileged user in s_user_ns to set file caps

On Fri, Dec 04, 2015 at 01:42:06PM -0600, Serge E. Hallyn wrote: > Quoting Seth Forshee (seth.fors...@canonical.com): > > A privileged user in a super block's s_user_ns is privileged > > towards that file system and thus should be allowed to set file > > capabilities. The file capabilities will

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

On Fri, Dec 04, 2015 at 02:07:36PM -0600, Serge E. Hallyn wrote: > Heh, I was looking over > http://www.gossamer-threads.com/lists/linux/kernel/103611 > a little while ago :) The same question was asked 16 years ago. Apparently > the answer then was that it was easier than fixing the code. So

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

On Fri, Dec 04, 2015 at 06:11:52PM -0500, Theodore Ts'o wrote: > On Fri, Dec 04, 2015 at 02:45:32PM -0600, Seth Forshee wrote: > > On Fri, Dec 04, 2015 at 02:07:36PM -0600, Serge E. Hallyn wrote: > > > Heh, I was looking over > > > http://www.gossamer-threads.com/lists/linux/kernel/103611 > > > a

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

> On Dec 4, 2015, at 4:11 PM, Theodore Ts'o wrote: > > On Fri, Dec 04, 2015 at 02:45:32PM -0600, Seth Forshee wrote: >> On Fri, Dec 04, 2015 at 02:07:36PM -0600, Serge E. Hallyn wrote: >>> Heh, I was looking over >>> http://www.gossamer-threads.com/lists/linux/kernel/103611 >>>

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

On Fri, Dec 04, 2015 at 05:43:49PM -0600, Serge E. Hallyn wrote: > On Fri, Dec 04, 2015 at 06:11:52PM -0500, Theodore Ts'o wrote: > > On Fri, Dec 04, 2015 at 02:45:32PM -0600, Seth Forshee wrote: > > > On Fri, Dec 04, 2015 at 02:07:36PM -0600, Serge E. Hallyn wrote: > > > > Heh, I was looking over

Re: [PATCH 10/19] fs: Update posix_acl support to handle user namespace mounts

Quoting Seth Forshee (seth.fors...@canonical.com): > ids in on-disk ACLs should be converted to s_user_ns instead of > init_user_ns as is done now. This introduces the possibility for > id mappings to fail, and when this happens syscalls will return > EOVERFLOW. > > Signed-off-by: Seth Forshee

Re: [PATCH 11/19] fs: Ensure the mounter of a filesystem is privileged towards its inodes

Quoting Seth Forshee (seth.fors...@canonical.com): > The mounter of a filesystem should be privileged towards the > inodes of that filesystem. Extend the checks in > inode_owner_or_capable() and capable_wrt_inode_uidgid() to > permit access by users priviliged in the user namespace of the >

Re: [PATCH 12/19] fs: Don't remove suid for CAP_FSETID in s_user_ns

Quoting Seth Forshee (seth.fors...@canonical.com): > Expand the check in should_remove_suid() to keep privileges for > CAP_FSETID in s_user_ns rather than init_user_ns. > > Signed-off-by: Seth Forshee Acked-by: Serge Hallyn > --- >

Re: [PATCH 13/19] fs: Allow superblock owner to access do_remount_sb()

Quoting Seth Forshee (seth.fors...@canonical.com): > Superblock level remounts are currently restricted to global > CAP_SYS_ADMIN, as is the path for changing the root mount to > read only on umount. Loosen both of these permission checks to > also allow CAP_SYS_ADMIN in any namespace which is

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

Quoting Seth Forshee (seth.fors...@canonical.com): > Signed-off-by: Seth Forshee Acked-by: Serge Hallyn > --- > fs/ioctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/ioctl.c b/fs/ioctl.c > index