does anyone else shadow users with a second login to divide privileges?

[ta0kira]

It occurred to me a few days ago that for most of my work I don't need a lot of the elevated permissions that I like to retain for my system. I do a lot of my work remotely via ssh, and I don't like how a compromise of that login would compromise my system, so I decided to give myself a second username with the same uid, home directory, etc. The only differences are the passwords, the groups, and the MAC labels. My "normal" user is part of all of the necessary groups for getting work done and has a less-restrictive set of MAC labels. My "admin" user is part of the wheel group, and has a more-restrictive set of MAC labels.

There are some complications that come along with this, however.

1. To change the password of the second account, you need to explicitly provide that username to passwd, but it doesn't require you to be root. This isn't much different than using the "toor" account, however.
2. The pam_self.so module causes a serious security hole because you can su/login from the "normal" user to the "admin" user, thereby changing groups, without so much as a password prompt. This can be solved by commenting out the pam_self.so lines in /etc/pam.d/*, however.

I keep my root account locked down, so it's really only good for getting myself out of a bind in init 1 to bring the system back up. I'd also like to be able to restrict login of the "admin" user outside of the LAN, but unfortunately the sshd options to control such things are somewhat obtuse.

Just wondering if anyone else does this, and/or if anyone knows of additional security risks involved. I think at worst it would be just like a compromise to the "admin" username, but hopefully trickery isn't the only thing this technique has going for it.

Thanks!

Kevin Barry

 

[kpa]

Aren't there other ways to get to your more priviledged user if they share the same UID. I can not come up with an example but to me it sounds like it could be trivial.

 

[ta0kira]

Aren't there other ways to get to your more priviledged user if they share the same UID. I can not come up with an example but to me it sounds like it could be trivial.

I only think it could happen via a suid-root program (su, login, sudo, passwd) or via a login program already running as root (sshd), since you can't arbitrarily add a group to a process, even if /etc/group says you're in the group (that would require the kernel to read /etc/group.) Canonical group membership is a userland thing, so the kernel trusts any root process to arbitrarily change gids and uids, but processes run as normal users can't add or remove groups. Without pam_self.so, su and login should ask for a password. passwd should unconditionally ask for a password. Without being in wheel, sudo should fail altogether. Everything that goes through PAM will verify the appropriate password, if it actually asks for a password.

As far as MAC labels, that's pretty bulletproof since nothing but the kernel itself can give a process a less-restrictive label, which it won't do.

If you can think of any other suid-root program I'm missing, please let me know. Also, I assume my reasoning that a process running as root must be involved to gain the additional groups is sound from my experience with related things in C, but if there's an exception I'd certainly like to know about it.

I don't plan to be any less cautious than I was when one user held all privileges, so if for some reason I think that the "normal" account has been compromised I'll consider the "admin" account also compromised. Hopefully the separation will at least slow them down.

Thanks!

Kevin Barry

 

[ta0kira]

One additional hole I found was .ssh/authorized_keys, which by default will be used to authenticate for both usernames. One part of the solution is to set "AuthorizedKeysFile %h/.ssh/authorized_keys.%u" in /etc/ssh/sshd_config, but it would still be possible for the "normal" user to add a login key for the "admin" user. I haven't figured out a solution for that, other than making an empty .ssh/authorized_keys for the "admin" username and only allowing root to edit/rename/delete it. Not particularly graceful; however, I did restrict logins for the "admin" user to IPs on the LAN in /etc/login.access.

In summary:

• It's only slightly more secure than giving the "normal" user all of the privileges the "admin" user has, and no less secure. For it to have any effect at all (other than self-annoyance,) you need to edit /etc/login.access, /etc/pam.d/*, and /etc/ssh/sshd_config to make sure the usernames are considered separate users for the purposes of accessing the system.
• It would never be practical for two different people; it's only effective for dividing up the privileges of one person.
• From what it seems like, you can essentially specify rules for when/where those extra privileges are allowed, e.g. using /etc/login.access.
• Basically, it's just a personal convenience, and one more thing to slow someone down if they have my password.

Kevin Barry

 

[fluca1978]

I'm surely missing out the whole point: in my experience using the same UID to share or shadow one user had been not so succesful. In particular, there could be somewhere an application that assumes that the UID is unique in the whole system, and that will surely be a possible security hole for this approach.
Despite the above, it does sound to me the security/sudo is already doing everything you need.

 

[ta0kira]

Despite the above, it does sound to me the security/sudo is already doing everything you need.

Not entirely, since there's more to process permissions than just users and groups. There are also resource limits and MAC labels, i.e. the things that go along with login classes. Some of those things can't be increased once decreased, even with a suid-root program. Also, anything that's group-readable and owned by root:wheel only needs wheel membership to read, without having to enter a password.

In particular, there could be somewhere an application that assumes that the UID is unique in the whole system, and that will surely be a possible security hole for this approach.

This is certainly the case, but like I said before, that's limited to suid-root programs and login processes that are already running as root. Some things can't be circumvented even by root, though, such as restrictive MAC permissions.

This is really a compromise between having one powerful uid and two uids with those privileges divided between them. I don't want two home directories, two mailboxes, two uids, etc. because some of the things I need to do overlap. I also don't want to log in as a member of wheel 10-15 times per day, and I'd like to use a slightly-different MAC label when logging in for admin-related things.

I think the main difficulty people will have with this, to include developers of software like sshd, is that traditionally "users" of a system have a name, are members of groups, have certain resource limits, have a particular home directory, etc., when in reality I can write a program that when run as root selects an arbitrary uid and an arbitrary set of gids and gives me a "Frankenstein" process that doesn't correspond to anything we consider to be a user of the system. The canonical "user's identity" only exists where the magic happens between fork and execvp in login-related processes, or when a program like id or pw looks it up. I'm merely trying to exploit that by removing group membership, etc. for processes that don't need them.

Kevin Barry

 

[fluca1978]

I think the main difficulty people will have with this, to include developers of software like sshd, is that traditionally "users" of a system have a name, are members of groups, have certain resource limits, have a particular home directory, etc., when in reality I can write a program that when run as root selects an arbitrary uid and an arbitrary set of gids and gives me a "Frankenstein" process that doesn't correspond to anything we consider to be a user of the system. The canonical "user's identity" only exists where the magic happens between fork and execvp in login-related processes, or when a program like id or pw looks it up. I'm merely trying to exploit that by removing group membership, etc. for processes that don't need them.

Well, Unix programs act already as you describe: they don't reason in terms of usernames and groupnames, but in terms of UIDs and GIDs, and usernames are just a match of an entry in the passwd database to make administrators life easier.
I still don't understand well your needs, but I have to confess I'm not an expert in the MAC context, so it could be my fault. However, I still suspect you are going to do things the harder way, this does not seem to me the right way of separating privileges.

 

[ta0kira]

However, I still suspect you are going to do things the harder way, this does not seem to me the right way of separating privileges.

In an ideal world I'd just have two completely separate users. That would take care of all of my requirements, except it would result in me having files owned by different uids, duplicate home directories, mailboxes, preferences, history files, etc. I did that for ~8 years, with one user for software development and another for normal work, but the separate history files, preferences, and uids made it extremely tedious at times. I'm mostly trying to avoid having to sudo to edit files or change permissions across two separate users who are both actually "me", since at the very least I'll want both users to have the same preferences, and at some point I'll be logged in as one user and I'll want to edit a file owned by the other user. I guess I could avoid that if I didn't set preferences for the "admin" account and didn't store any files.