Utilities don't take into account capabilities

Utilities don't take into account capabilities

[Steven Stewart-Gallus]

The utilities such as mount don't take into account capabilities and always fail
for non root users which is wrong.

This is really, really, really annoying when working in a sandboxed non root
shell with pseudo capabilities.

One possible solution to my problem is do some complicated checking for
capabilities that I don't even know how would work. I believe a better and
simpler approach that would work for possible future extensions as well would be
to simply drop privileges whenever one is unprivileged and attempt to do the
task as normally. If you felt like it, a warning along the lines of "warning:
user is unprivileged, attempting mount without privileges" could be made. As a
bonus, failed system calls can sometimes leave important diagnostic information
in the dmesg.

Thank you,
Steven Stewart-Gallus

Re: Utilities don't take into account capabilities

[Linda Walsh]

Steven Stewart-Gallus wrote:
> The utilities such as mount don't take into account capabilities and always fail
> for non root users which is wrong.
>
> This is really, really, really annoying when working in a sandboxed non root
> shell with pseudo capabilities.
----
I was just going to ask what capabilities need to be set for mount to work.

Seriously... What capabilities does mount need in order to function?


If this is in the 'util-linux', shouldn't these be utilities for 
linux?   I.e.
the default linux kernel supports capabilities these days...no?

Re: Utilities don't take into account capabilities

[Steven Stewart-Gallus]

> Seriously... What capabilities does mount need in order to function?

I can help out with this one.

> CAP_SYS_ADMIN
>        * Perform  a  range  of  system administration operations including:
quotactl(2),
>          mount(2), umount(2),  swapon(2),  swapoff(2),  sethostname(2),  and 
setdomain‐
>          name(2);
>        * perform  privileged syslog(2) operations (since Linux 2.6.37,
CAP_SYSLOG should
>          be used to permit such operations);
>        * perform IPC_SET and IPC_RMID operations on arbitrary System V IPC
objects;
>        * perform operations on trusted and security Extended Attributes (see
attr(5));
>        * use lookup_dcookie(2);
>        * use  ioprio_set(2)  to  assign  IOPRIO_CLASS_RT  and  (before   Linux
  2.6.25)
>          IOPRIO_CLASS_IDLE I/O scheduling classes;
>        * forge UID when passing socket credentials;
>        * exceed  /proc/sys/fs/file-max,  the  system-wide  limit  on  the
number of open
>          files, in system calls that open files (e.g.,  accept(2),  execve(2),
 open(2),
>          pipe(2));
>        * employ CLONE_NEWNS flag with clone(2) and unshare(2);
>        * call setns(2);
>        * perform KEYCTL_CHOWN and KEYCTL_SETPERM keyctl(2) operations;
>        * perform madvise(2) MADV_HWPOISON operation.

>From CAPABILITIES(7) in the Linux Programmer's Manual.

Re: Utilities don't take into account capabilities

[Linda Walsh]

Steven Stewart-Gallus wrote:
>> Seriously... What capabilities does mount need in order to function?
>>     
>
> I can help out with this one.
>   
----
awesome... but, um... was hoping the author of mount could
tell me what caps I needed to enable to use his program
w/a non-root user... ;-)... oh well... um...now as to when we
can get a version that doesn't check for UID & EUID==0?

well... maybe in the works?

Re: Utilities don't take into account capabilities

[Dale R. Worley]

> From: Linda Walsh <lkml@tlinx.org>
> 
> Steven Stewart-Gallus wrote:
> >> Seriously... What capabilities does mount need in order to function?
> >>     
> >
> > I can help out with this one.
> >   
> ----
> awesome... but, um... was hoping the author of mount could
> tell me what caps I needed to enable to use his program
> w/a non-root user... ;-)... oh well... um...now as to when we
> can get a version that doesn't check for UID & EUID==0?
> 
> well... maybe in the works?

I believe there's a complication...  I'm no expert, but I vaguely
recall from some previous thread that there are situations where
'mount' isn't purely a front-end for the kernel mount() call.
Instead, 'mount' wants to set up some things and then call mount().

The example that comes to mind is setting up a file on a loopback
device, then mounting the loopback device.  But I think there were
other situations like this.

The problem being, that 'mount' wants to verify that the mount() call
will succeed *first* before attempting the set-up operations.  And
some of the setup operations require root capabilities.

There's also the complication of the "users" and "user=" options,
which are to permit a user to do something he doesn't actually have
the capabilities for.

Dale

Re: Utilities don't take into account capabilities

[Linda Walsh]

Dale R. Worley wrote:
>
> I believe there's a complication...  I'm no expert, but I vaguely
> recall from some previous thread that there are situations where
> 'mount' isn't purely a front-end for the kernel mount() call.
> Instead, 'mount' wants to set up some things and then call mount().
>
> The example that comes to mind is setting up a file on a loopback
> device, then mounting the loopback device.  But I think there were
> other situations like this.
----
    In such cases, to execute the operation, check the max caps needed
to perform the operation. 
>
> The problem being, that 'mount' wants to verify that the mount() call
> will succeed *first* before attempting the set-up operations.  And
> some of the setup operations require root capabilities.
>
> There's also the complication of the "users" and "user=" options,
> which are to permit a user to do something he doesn't actually have
> the capabilities for.
----
      Separate issue.  I.e. should permission come from the entry in 
'fstab', or
should it come from what logins are set w/what caps.  I think (?) from 
historical
perspectives, the user is enabled to perform a specific operation if 
they are specifically
mentioned.  Else, go/w caps user has to complete successful operation.

    Would that cover it?

Re: Utilities don't take into account capabilities

[Dale R. Worley]

> From: Linda Walsh <lkml@tlinx.org>

>     Would that cover it?

I have no idea.  I just wanted to warn you that it's probably trickier
to do well than it appears at first.

Dale

Re: Utilities don't take into account capabilities

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Sat 16 Aug 2014 21:57:56 Steven Stewart-Gallus wrote:
> The utilities such as mount don't take into account capabilities and always
> fail for non root users which is wrong.
> 
> This is really, really, really annoying when working in a sandboxed non root
> shell with pseudo capabilities.
> 
> One possible solution to my problem is do some complicated checking for
> capabilities that I don't even know how would work. I believe a better and
> simpler approach that would work for possible future extensions as well
> would be to simply drop privileges whenever one is unprivileged and attempt
> to do the task as normally. If you felt like it, a warning along the lines
> of "warning: user is unprivileged, attempting mount without privileges"
> could be made. As a bonus, failed system calls can sometimes leave
> important diagnostic information in the dmesg.

guessing the sandbox isn't really meant for security purposes since 
CAP_SYS_ADMIN can easily be used to recover just about every other capability.
	http://lwn.net/Articles/486306/

especially considering access to mount means you're allowed to mount arbitrary 
filesystems w/arbitrary content including set*id progs.

so what exactly is the point of trying to support CAP_SYS_ADMIN ?

note: i'm not arguing about whether the current UID checks in `mount` are even 
useful ... it'd make the code simpler to just assume the privs exist, else 
it'll get errors from the respective syscalls and the user of a misconfigured 
system can deal with it themselves.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Utilities don't take into account capabilities

[Steven Stewart-Gallus]

> guessing the sandbox isn't really meant for security purposes since 
> CAP_SYS_ADMIN can easily be used to recover just about every other 
> capability.	http://lwn.net/Articles/486306/

capabilities in a CLONE_NEW_USER sandbox only apply to the sandbox and not
things outside of the sandbox such as devices.

Re: Utilities don't take into account capabilities

[Karel Zak]

On Mon, Aug 18, 2014 at 05:40:19PM +0000, Steven Stewart-Gallus wrote:
> > guessing the sandbox isn't really meant for security purposes since 
> > CAP_SYS_ADMIN can easily be used to recover just about every other 
> > capability.	http://lwn.net/Articles/486306/

 The currently supported scenario is that you can remove suid from
 mount(8) and replace it with cap_dac_override,cap_sys_admin+ep. Note
 that in this case mount(8) still requires 'user' in fstab of course.
 
 The disadvantage is that mount(8) is not able to update for example
 /etc/mtab (or /run/mount/utab), because cap_sys_admin is just subset
 of the original suid privileges.
 
> capabilities in a CLONE_NEW_USER sandbox only apply to the sandbox and not
> things outside of the sandbox such as devices.

 Well, user namespace is little bit different story and we already
 talked about it (in May).
 
   http://www.spinics.net/lists/util-linux-ng/msg09309.html
 
 The idea is that we can drop privileges rather than exit with "only
 root can..." error message. I'd like to try it during this release
 cycle.

    Karel



-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Utilities don't take into account capabilities

[Steven Stewart-Gallus]

I see, so the issue is already known. Thank you.

Re: Utilities don't take into account capabilities

[Linda Walsh]

Karel Zak wrote:
> The currently supported scenario is that you can remove suid from
>  mount(8) and replace it with cap_dac_override,cap_sys_admin+ep. Note
>  that in this case mount(8) still requires 'user' in fstab of course.
>   
---

   Is this planned, as the source I looked at still had uid==0 checks.
> 
>  The disadvantage is that mount(8) is not able to update for example
>  /etc/mtab (or /run/mount/utab), because cap_sys_admin is just subset of
>  the original suid privileges.

        This does point out an important issue -- should things like
cap_sys_admin also allow updating of run/mount/utab?  I would say "maybe":

        Updating /etc/mtab -- IF it is a separate file system object would
require write access to the file.  That could be handled with an ACL, or
CAP_DAC_OVERRIDE.  But the former "/run/mount/utab" -- isn't that a kernel
based file?  I.e. a pointer to /proc/self/mounts?  Either way -- if it is
a separate file, then it would be updated based on access and privilege,
but if it is a representation of kernel state, then it seems CAP_SYS_ADMIN
would be sufficient, no?


Linda