Summary: Incomplete user-locking procedures can fail, leaving opportunities for them to maintain access to your system without your consent.

Last week I showed you some of the ways you can lock users out of your system. As a reminder, the best plan, regardless what tools you use, is to do the following:

• Remove all files owned by the user from the entire machine. You may want to back them up for reference later, but make sure to put those backups somewhere only accessible by root.

• Remove the user's entry from /etc/shadow.

• Remove any other non Linux native authentication methods, such as smbpasswd entries, LDAP entries, or .htpasswd-style entries.

• Place a '-' in front of the user's entry in /etc/passwd. The user will no longer exist, but you still have a convenient place to see that it once belonged to that specific account.

• Remove files associated with the locked user that may not be owned by him, for example /var/spool/cron/crontabs/USERNAME.

• Kill all user processes running under the newly locked userid.

The above list is pretty thorough, but if anyone thinks of something I didn't, please slap me upside the head...

Anyway, the reason this whole thing came up is because a reader had mysterious processes running under a uid that had been locked out. The home directory and other files created by the user were long gone, and they had completely removed the /etc/passwd entry from the system, yet the processes continued.

It may have been that the locked user had planned ahead and had processes running to maintain access ahead of time, or it could be that he was actually logged in when the account was deleted.[1]

The interloper was still able to do everything you can as a normal user, such as start processes, create files, download software. Surprisingly few actions actually require you have a valid username or account -- if you have a uid (and if you're running a process, it must be running as someone) that's all the kernel needs to be able to do it's job. True, you might have trouble sending email or other things that want to find your user information, but those aren't the types of activities you're likely to be engaged in when your account has been locked.

So I can't tell you for sure how the user managed to stay on, but here are a variety of methods. There are certainly more. Most of these are not possible if you remove the /etc/passwd entry, which is why it is imperative that you do that rather than simply lock the user's password.

Crontabs and Atjobs

A user can launch processes via his cronjobs or atjobs. The crontab and at files are usually owned by root, so deleting the user's files will not affect these. Luckily these will usually not run on newer crond and atd daemons because they check for the user account before running them.

Email Triggers

If the user can still receive email, the .forward or .procmailrc files can cause processes to be run, if set up ahead of time.

Existing Processes

If a user has processes running when the account is locked, for example if the user is still logged in, these can still be used. For example the user may run an inbound login service under his uid that will last until the next reboot, and can access the locked account that way.

Additional Authentication Measures

A user who has a locked password but valid account can still log in with alternate authentication schemes, such as using SSH identities, Samba, Apache .htpasswd files, and anything else not controlled by standard /etc/shadow passwords.

Suid programs

If you don't delete all files owned by the locked user, he can leave set-user-id programs on your system that would allows others to assume his uid. If he has compromised an account on this system, he can use the suid program to become his old uid, which makes tracing his actions much harder.

Dynamic Web pages

If a user could create a CGI, PHP script, etc, he could create one that runs commands as the webserver user or his id if suEXEC is in place. These can be left behind when the user is kicked off, and allow him to run commands without logging in at all.

NOTES:

[1] I've been in this situation, where my account was nuked while I was still logged in. This was due to an error on the part of another administrator who trashed /etc/passwd, but you better believe I stayed logged in and because of that we were able to fix the machine.

Of course this wasn't nearly so bad as when someone moved /usr/lib/libc.a and we needed to resort to re-creating it from the command line manually...

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He wields a large cudgel when locking down machines and users. A real one, I'm not talking figuratively. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002

This is the November 20, 2002 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.