Interactions between POSIX.1e privileges and "user mounts"

[Andrew Morgan]

Isn't there some tie in with the nature of the device - one captured 
outside the capability/privilege model?

That is, writing to a CDR, or a floppy is a trivial thing, and thus a 
system would likely want to be configured to resist accepting 
capabilities of any flavor from executable content on these devices. But 
a networked filesystem and/or a hard drive within the physical machine, 
has some potential for being more trustworthy - either through strong 
authentication at mount time, or physical security.

In the spirit of POSIX.1e capabilities, it is processes that exert 
privilege and not 'users', so isn't the issue one of 'what executable is 
allowed to mount' and 'what authentication does that executable require 
of the requesting entity'?

Automounters have some protected configuration file defining what they 
will automount, and what can be done from the automounted media.

And 'user mounts/umounts' generally require some tool to perform the 
mounting/unmounting. Can't the policy get enforced by these 'trusted 
binaries' through system configuration?

Thanks

Andrew

Pawel Jakub Dawidek wrote:
> On Tue, Dec 16, 2003 at 04:35:29PM -0500, Robert Watson wrote:
> +> [...] Should an unprivileged root user be able
> +> to mount/update a file system mounted by a privileged root user?
> +> 
> +> The first two answers to pop into my head were:
> +> 
> +> (1) Yes.  If the administrator enables usermounts, and there's not another
> +>     policy (such as MAC) that prohibits the operation, the root user
> +>     should be able to unmount a file systems it "owns".
> +> 
> +> (2) No.  We should track whether a file system was mounted with privilege,
> +>     and only permit update/unmount with privilege, or some of the inherit
> +>     tie-in with integrity models will break down.
> 
> Yes, the main problem is not sufficient definition of root user, because
> it can be privileged user or not. Answer 2 is of course much more complete
> and correct. So 'privileged' attribute should be absolutely not related
> to uid. If we will define 'privileged' as current definition of root user
> and we introduce some process flag (cred flag better) IS_PRIVILEGED that
> could be set to any uid this will be most complete solution.
> Of course we want to run away from today's 'god, root, what difference?',
> but any capabilities should be totally uid-independent and only for
> backward compatibility those attributes should be set for uid 0 by default.
> 
> It this example we should add information to file system if it was
> mounted with or without privileges.
> 
> I'm wondering if there aren't more issues releated to this possibility
> (possibility to change root user to unprivileged user).
> 


To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message