My SE Linux Play Machine [1] has been online again since the 18th of March.
On Monday the 11th of Feb I took it offline after a user managed to change the password for my own account (their comment was “ohls -lsa! i can change passwordls -lsals -lsa HACKED!“). Part of the problem was the way /bin/passwd determines whether it should change a password.
The previous algorithm (and the one that is currently used in Debian/Etch) is that if the UID of the account that is having it’s password changed doesn’t match the UID of the process that ran /bin/passwd then an additional SE Linux check is performed (to see if it has permission to change other user’s passwords). The problem here is that my Play machine has root (UID==0) as the guest account, and that according to the /bin/passwd program there is no difference between the root account (for unprivileged users) and the bofh account (which I use and which also has UID==0). This means of course that users of the root account could change the password of my account. My solution to this was to run chcon on the /bin/passwd program to give it a context that denied it the ability to change a password. The problem was that I accidentally ran the SE Linux program restorecon (which restores file contexts to their default values) which allowed /bin/passwd to change passwords, and therefore allowed a user to change the password of my account.
The semanage tool that allows changing the default value of a file context does not permit changing the default for a file specification that matches one from the system policy (so the sys-admin can’t override compiled in values).
I have now fixed the problem (the fix is in my Etch SE Linux repository [2] and has been accepted for Debian/Unstable and something based on it will go into the upstream branch of Shadow. See the Debian bug report #472575 [3] for more information.
The summary of the new code is that in any case where a password is not required to change the user’s password then SE Linux access checks will be performed. The long version is below:
The new algorithm (mostly taken from the Red Hat code base which was written by Dan Walsh) is that you can only change a password if you are running as non-root (which means that the pam_unix.so code will have verified the current password) or if you are running as root and the previous SE Linux security context of the process is permitted access to perform the passwd operation in the passwd class (which means it is permitted to change other user’s passwords).
The previous context (the context before one of the exec family of system calls was called) is used for such access checks because we want to determine if the user’s shell (or other program used to launch /bin/passwd) was permitted to change other user’s passwords – executing a privileged program such as /bin/passwd causes a domain transition and the context is different) than the program that was used to execute it. It’s much like a SETUID program calling getuid(2) to get the UID of the process which launched it.
To get the desired functionality for my Play Machine I don’t want a user to change their own password as the account is shared. So I appended password requisite pam_deny.so to the file /etc/pam.d/passwd (as well as the chfn and chsh commands) so that hostile users can’t break things. The new code in /bin/passwd will prevent users from taking over the machine if my PAM configuration ever gets broken, having multiple layers of protection is always a good thing.
The end result is that the Debian package and the upstream code base are improved, and my Debian Etch repository has the code in question.
that’s me, actually.
after i changed the password, i have tried to login with your account. but it didn’t work.
either i have entered a bad password, or you have other security measure in place.
Daniel: Strange, there is no reason why it shouldn’t have worked. At the minimum you prevented me from doing a password based login to my own account which counts as breaking the security goals of the box.
Thanks for the comment on this blog post and the comment in the thanks.txt file.
In future I would appreciate it if you could send me your email address in a suitable location (such as thanks.txt) so we could discuss them before I write a post about them. Or of course an email would do (my address is well publicised).
Russell,
A more generic Debian safety/security question, especially after you’ve mentioned incident with “restorecon”:
Is in Debian any way of keeping records of all local per machine customisations of security policies (SELinux or other like regular file permissions), regulary verifying them and fixing/sending reports when found different?
For instance, I have a some limited rights (made via file group permissions) on my general-purpose-machine for all kind of active browser content (flash etc), but they are gone every time I’m updating the software.
Would it be right to configure SELinux for it or it is still better to make a virtual machine with all browsers?
Thanks, Pavel.