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.