grm blog. Work is copyrighted unless otherwise stated.
2022-11-28 Mon
^

Sticky sticky bit

$ whoami
user
$ echo "Hello from user" > file
$ cat file
Hello from user
$ sudo su -
$ whoami
root
$ echo "Hello from root" > file
-bash: file: Permission denied

Powerless root

I was copying some stuff around in a host when all of a sudden my root account couldn't write to a file. My initial thoughs were that the file is being kept open by another process or that there has been some kind of filesystem shenanigans. When both these ideas came fruitless I had an epiphany that this might be related to the sticky bit. What I hid from the introductory example is the $PWD which happens to be /tmp.

Finding documentation

It all started years ago with noticing a t in the ls -l /tmp permission bits output.

# ls -ld /tmp
drwxrwxrwt 17 root root 1000 Nov 28 14:27 /tmp
# ______-^-__

A quick serch for t in the ls manpage was not promising so the easy solution for the 21st century is to google it, which besides giving some definitions from random sites it hinted that the answer would be in the chmod(1) manpage:

[…] The letters rwxXst select file mode bits for the affected users: read (r), write (w), execute (or search for directories) (x), execute/search only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), restricted deletion flag or sticky bit (t). […]

which leads to the following section:

RESTRICTED DELETION FLAG OR STICKY BIT

The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit.

man chmod must be the authority for what the sticky bit means. Right? So since /tmp has the sticky bit set AND it is owed by root it means that files inside /tmp can be deleted by the root as well as the user owning the file.

This is very usefull for directories like /tmp so many users can write but they can't delete each other's stuff. And you get all this in the standard linux permission system without having to use SElinux and the likes.

Back to the useless root

So here I am years later, with my epiphany about the permission-less root, and firmly believing there is something going on with the sticky bit. I verify my thesis by running the introductory proof of concept inside /tmp and outside of it and then start looking at the kernel sources for an answer.

So inside a directory with the sticky bit set, when there is a file owned by a user other than root, the root user can delete it (as stated in the chmod manpage) but it cannot modify the file.

The solution

Turns out this is intentional and here is a link to the commit adding this feature in the kernel's permission system. So fs.protected_regular basically disallows users to overwrite other user's files in world-writable directories with the sticky bit turned on, and in doing so prevents a family of local attacks for root privileges.