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]

Date:	Fri, 20 Apr 2007 10:33:13 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
	viro@....linux.org.uk, linuxram@...ibm.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)

"Serge E. Hallyn" <serue@...ibm.com> writes:

> 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.

Agreed.  It appears the approach of adding owner ship information to
mount points and using that to control what may happen with them
in regards to mount/unmount is the only workable approach in the
unix environment.

Now to dig into the details and ensure that they are correct.

Eric
-
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/