3

I have a bash script started with cap_sys_admin,cap_setgid,cap_setuid+i (which means those capabilities are inheritable), what is the command for becoming root without typing password (note this simply means using setreuid(0,0)) ?

The aim is to perform this while not being in developer mode, nor turning rootfs verification off. This mean I can’t call a wrapper I would have written myself nor I can use python or perl unless there is a way to use cap_sys_admin to remount a partition exec.
The script is started during the boot process.

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – DavidPostill
    May 22, 2017 at 17:57

3 Answers 3

4
+25

My first observation, is that you have 3 capabilities. Are you trying to ask how to escalate your capability set to all capabilities by becoming root? At first glance it seems like you are trying to gain all capabilities (by becoming root) while having only 3.

Second observation is that you don't specify what the system's capability is bounding set is. I.e. if the overall bounding set is only those 3 capabilities, then becoming root will have no effect.

Third observation is that you don't specify what the "securebits" are. Depending on their value it may be impossible to add any further capabilities or it may be the case that becoming root does nothing more than change your UID (i.e. root is no longer special).

Fourth observation -- while you are starting your bash shell with the listed capabilities, you don't show that bash has actually retained those capabilities. You might want to make sure.

But I'll go with observation #1 and say that what you are asking shouldn't be possible. If it is, it seems like it would be a kernel security bug -- specifically a privilege escalation. If you do find a way to do it, I would think it wouldn't stay around long, as security bugs are usually fixed ASAP.

Am I missing something in your use-case as to why this wouldn't be a security bug?

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – DavidPostill
    May 22, 2017 at 17:55
2

New answer : Not possible unless you are willing to take the risks, which as you you have indicated (wisely), you are not willing to take.

To summarize the problem:

  1. All disks except rootfs are mounted as noexec, so can contain scripts but not programs
  2. Rootfs (the system) is checksumed and cannot be modified
  3. System-modifying verbs are only allowed in development mode (admin)
  4. The remount of disks with exec is only possible in development mode
  5. Unless in development mode, suid and system-modifying capabilities are not operational.

Solutions and workarounds:

  1. Programs can be executed by a script begins with she-bang line (begins with #!) that will run the executable named on that line. But unless in development mode, only a limited number of programs from rootfs can be executed in this way.
  2. Remove rootfs verification and make the file system writable via
    sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
    See link with warnings.
  3. Write your own rootfs with checksum (link to deleted doc in google cache).

[Old answer]

You have asked for the CAP_SYS_ADMIN capability, which amounts to root permission as it grants the ability to mount/unmount filesystems, so to bind mount a new filesystem over an existing one to backdoor any binary on the system.

As in Chrome OS a large effort was done to block all security holes, up to and including blocking suid when not in dev mode, I do not know if capabilities were also blocked, and I do not have a Chromebook to test (but you do).

Such capabilities can be granted via :

$  sudo setcap cap_sys_admin+ep executable

References:

15
  • You have asked for the CAP_SYS_ADMIN capability, which amounts to root permission as it grants the ability to mount/unmount filesystems No I have asked how to use use it because the mount command refuse to work with capabilities (so it refuses to run if ᴜɪᴅ isn’t 0). And again, I said I don’t want to turn rootꜰꜱ verification off. May 11, 2017 at 12:14
  • Look, what you are asked is to check if setcap with the capabilities you wanted do work or not when dev mode is off. If they don't, then your question stays without any possible answer. You seem to believe that the exploit you found is the only solution - even if it works for your Chromebook it might still not work for a newer kernel.
    – harrymc
    May 11, 2017 at 12:40
  • is to check if setcap with the capabilities you wanted do work or not when dev mode is off. No, I know they works, because I launched getcaps on the ᴘɪᴅ of the bash process and it printedcap_sys_admin,cap_setgid,cap_setuid+eipon the screen. The question is about becoming an other user through capabilities and without using a password. May 11, 2017 at 12:58
  • If capabilities work in general, you could try CAP_SETUID and CAP_SETGID.
    – harrymc
    May 11, 2017 at 13:27
  • Yes, but what is the bash command which allows to perform the setreuid()/setregid() system call ? May 11, 2017 at 13:28
2

The answer is simple as mount.exfat-fuse rely only on permissions and does not check for ᴜɪᴅ 0 :

/sbin/mount.exfat-fuse /media/removable/Y/dev /media/removable/archive -o exec,nonempty

Of course, this only works for the versions I care about as exfat-fuse has been upgraded thanks to my finding.

2
  • Your solution is to run another mount program that doesn't check UID==0. Fine, now suppose that's updated tomorrow and that's changed? You miss the point on my post -- if you compile your own mount prog, you don't have to do any checks nor worry if the binaries are updated tomorrow.
    – Astara
    May 15, 2017 at 10:18
  • @Astara I only care about version r58 and below of chrome. Also you cannot install binary executable without partizlly disabling rootfs verification. May 15, 2017 at 12:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .