3

I've written and compiled a short program to allow any user to change the contents of my /sys/class/backlight/intel_backlight/brightness file, but I fail to escalate their permissions. What could I be missing.

#include <stdio.h>
#include <stdlib.h>
#define FILENAME "/sys/class/backlight/intel_backlight/brightness"

int main (int argc, char * argv[])
{
    int res;
    setuid(0); // I didn't intend to keep this, but I included it just in case
    printf("euid %d\n", geteuid());
    system("whoami");
    // Attempt to open FILENAME; print "Can't open..." on failure
}

Yet, whoami consistently returns exampleuser instead of root, and the program consistently fails to open the output file.

I compile it and set the uid bit then run the program:

$ gcc -o example.bin example.c     # compile
$ sudo chown root:root example.bin # set owner & group
$ sudo chmod 4770 example.bin      # set uid bit
$ ./example.bin 75                 # execute
euid 1000
exampleuser
Can't open output file /sys/class/backlight/intel_backlight/brightness

The target output file does exist:

$ ls -l /sys/class/backlight/intel_backlight/brightness
-rw-r--r-- 1 root root 4096 May  2 07:57 /sys/class/backlight/intel_backlight/brightness

I'm running Ubuntu 14.04 LTS

  • 1
    Is the filesystem on which example.bin is located mounted with nosuid? Also, I suggest id -a as a more comprehensive test command instead of whoami. I am not sure but I think who and/or whoami obtain information from utmp which could cloud the facts. – Celada May 2 '15 at 20:07
1

Either the filesystem is doesn't support setuid executables (because it's mounted with the nosuid option, or because it's a FUSE filesystem mounted by a non-root user), or there is a security framework such as SELinux or AppArmor that prevents setuid here (I don't think Ubuntu sets up anything like this though). That, or you didn't actually run these commands — you've made the file non-executable by others, so they'd only work if you were in the root group, which you shouldn't be.

This isn't a good way to do it anyway. It's a lot simpler to change the permissions on the file.

chgrp users /sys/class/backlight/intel_backlight/brightness
chmod g+w /sys/class/backlight/intel_backlight/brightness

Use a group that you're a member of, if you aren't a member of the users group.

Add these commands to /etc/rc.local or some other script that is executed near the end of the boot sequence.

  • Thanks for the alternative design. As for the nosuid option, mount reveals that the device on which example.bin resides has no such restriction: /dev/sda5 on / type ext4 (rw,errors=remount-ro). I don't believe I'm using any unusual frameworks except for encryption of the home folder with encryptfs-utils. – JellicleCat May 2 '15 at 22:21
  • I did run the commands, and I am in the root group, for better or worse. – JellicleCat May 2 '15 at 22:25
  • The file I wish to modify, however, is on a device mounted with nosuid. I wouldn't expect that to make a difference, but do you know otherwise? – JellicleCat May 2 '15 at 22:26
  • @JellicleCat Ah, so the file is on a filesystem which doesn't support setuid — it's on ecryptfs (if it's on the encrypted part, it isn't on the / filesystem). I forgot to mention that case. – Gilles May 2 '15 at 22:27
  • 1
    @JellicleCat Is example.bin in your (encrypted) home directory, or on the / filesystem? The fact that /sys doesn't support setuid is irrelevant. – Gilles May 2 '15 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.