linux-kernel - Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070420124249.GC29498@sergelap.austin.ibm.com>
Date:	Fri, 20 Apr 2007 07:42:49 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	akpm@...ux-foundation.org, viro@....linux.org.uk,
	linuxram@...ibm.com, ebiederm@...ssion.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	containers@...ts.osdl.org
Subject: Re: [patch 0/8]  mount ownership and unprivileged mount syscall (v4)

Quoting Miklos Szeredi (miklos@...redi.hu):
> This patchset has now been bared to the "lowest common denominator"
> that everybody can agree on.  Or at least there weren't any objections
> to this proposal.
> 
> Andrew, please consider it for -mm.
> 
> Thanks,
> Miklos
> ----
> 
> v3 -> v4:
> 
>  - simplify interface as much as possible, now only a single option
>    ("user=UID") is used to control everything
>  - no longer allow/deny mounting based on file/directory permissions,
>    that approach does not always make sense
> 
> ----
> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.
> 
> The mount owner has the following privileges:
> 
>   - unmount the owned mount
>   - create a submount under the owned mount
> 
> The sysadmin can set the owner explicitly on mount and remount.  When
> an unprivileged user creates a mount, then the owner is automatically
> set to the user.
> 
> The following use cases are envisioned:
> 
> 1) Private namespace, with selected mounts owned by user.
>    E.g. /home/$USER is a good candidate for allowing unpriv mounts and
>    unmounts within.
> 
> 2) Private namespace, with all mounts owned by user and having the
>    "nosuid" flag.  User can mount and umount anywhere within the
>    namespace, but suid programs will not work.
> 
> 3) Global namespace, with a designated directory, which is a mount
>    owned by the user.  E.g. /mnt/users/$USER is set up so that it is
>    bind mounted onto itself, and set to be owned by $USER.  The user
>    can add/remove mounts only under this directory.
> 
> The following extra security measures are taken for unprivileged
> mounts:
> 
>  - usermounts are limited by a sysctl tunable
>  - force "nosuid,nodev" mount options on the created mount

Very nice.  I like these semantics.

I'll try to rework my laptop in the next few days to use this patchset
as a test.

thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/