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.

karel
  • 13,706
user2284570
  • 2,020

3 Answers3

4

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?

Astara
  • 659
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:

Community
  • 1
harrymc
  • 498,455
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.

user2284570
  • 2,020