Some of the applications we run in our RHEL environment are owned by a specific user account that was created just for this use. Our application requires this file/directory ownership in order to function.

I am eliminating the poorly designed internal process of allowing everyone to use sudo to act as root in order to make changes and instead forcing everyone to login using their own user account. Once logged in they will us su to change to this existing account so that they have the required permissions to administer the application without having root like access.

Is there a way to allow users to become this user (after logging in as themselves) while preventing them from using ssh to access the box as this user?

I would say that the "current" process seems better over all. sudo provides much better auditing opportunities than a single account... once you su to your "special" account, you no longer have a clue who is doing what. control the /etc/sudoers file better, using additional *group* membership attributes to provide granularity for each service that is running on a shared machine and you'll be in a much nicer place.

I tried using the /etc/sudoers file and the additional group memberships setup however the problem I ran into trying to do this was that while using LDAP for user authentication it didn't seem that sudo was recognizing the users' additional group assignments that are stored in LDAP. When I tried to run anything granted via sudo it was failing.

The way to do this is simple.

As root user set a real (and difficult to guess) password on the Administrative accounts.

Allow the users to do "sudo su <adminacct>" and "sudo su - <adminacct>".

Since the user became the administrative account user via sudo they only needed to know their OWN password and not the one you set on the administrative account. Even if they try to change the password after they do the "sudo su..." they'll fail because only root can change a password without providing the existing password.

That is to say if they type "password" or "password <adminacct>" they'll be prompted for the EXISTING password which they don't know so they can never circumvent the sudo method of gaining access by setting a new password themselves.

While Acid_Kewpie does have a bit of a point I disagree with him because for many items (e.g. Oracle software) you do need a common administrative account to own the software and because of that you do need to let a responsible group (DBAs) have access to that account. With sudo you at least get a log of which real user became the admin user and at what time they did.

We even require ourselves (UNIX/Linux admins) to login under our IDs and do sudo su to root for most purposes. Obviously we still have to have access to root password for those times when everything else fails but by policy we do not login as root directly except in situations where doing it the sudo way wouldn't work.

Makes sense, what you are suggesting is to allow sudo to manage access to this admin account, which only requires their own password, instead of simply allowing users to substitue as the user, which requires knowledge of that user's actual password. Since they don't know the password they can't login via SSH....nice.

Any idea how to get sudo to recognize the group assignments stored in LDAP so I can assign permissions to this admin account without having to add every user to the sudoer file?

"sudo su -" is a nasty hack. horrible and should be prevented. massive security flaw. Well that's my take on it at least - have you seen this in a best practise guide ever? This approach still does use sudo and sudoers level control to some extent though.

With oracle accounts and such, we have files owned by an oracle user, but never log in with that user. Although, TBH, that is the **theory**

man sshd_config and checkout the DenyUsers directive.

I do the same thing on my RHEL servers for application accounts. Deny them direct ssh access and require them to su to the account.

Not exactly true. Requiring a user to use 'sudo rootsh -u root' provides audit logging, ergo providing the same crossing over from the unprivileged to the intermediate account will work as well (just give a thought to log entry correlation). Just make sure to log to file or use a local facility in syslog.conf because the amount of logging can grow quickly.

Wrt to denying accounts and sshd_config's DenyUsers there's one other method: on systems with PAM you can use pam_listfile.

you can see a user becoming root, but on a busy server with multiple people having done that, you're not going to have a clue which root did what.

Is that conclusion based on actually using multiple rootsh sessions or?

I don't really see it as the "nasty" security flaw you do. If you read my post ONLY system admins that already have access to the root password can do the "sudo su -" to root.

As to allowing "sudo su - <adminacct>" I don't really see the issue. Given the issues we had just getting them to use sudo in the first place I doubt we'd have gotten it through at all if we'd required them to give us every possible command to put in sudo. In fact in other organizations what I've seen them do is "temporarily" give root access to DBAs for "installs" and "patches". At least we were able to avoid doing that here.

What kind of service are we talking about? A big mistake is to have the config files for a service owned by the system user. The system user should not have write access to it's config files. For example, if an Apache server were run this way, and someone could gain access to these files as "www", then he could modify the config to run the service as root. After the server is restarted this way, the next time the cracker gets root access.

If this service doesn't use ssh, then the service user shouldn't have ssh access anyway. Look at "AllowUsers" in sshd_config to control exactly who has ssh access, and even from where. Also look at the sshd manpage. You can have the entry from="patternlist" option given in the public key. If ssh is used to launch the service, or to create a tunnel, you can have "nopty" and "command=" in the key as well.

The two advantages of sudo are in not needing to distribute the root password and logging. A mistake is more likely than malicious activity by some one you trust to configure your service. The logging can help reverse a mistake.

You can do things like only allowing the users to use rvim. Explicitly listing the commands run, using the restricted bash shell, controlling the environment, etc. How much work you need to lock down your sudoers file probably is inversely proportional to how trustworthy your admins are. If they aren't isn't that your own fault in selecting them.

Allowing system users to log into the server, root ssh logins, not using pubkey authentication, and not using a strong passphrase to protect clients private key may be as serious as your concerns about sudo.

Assuming OP has not abandoned this thread...

@ciphyre:

I wanted to add that we have a similar dilemma for Oracle DB / applications running on RHEL. In my case, I have made DBAs full sudoers for installation and maintenance purposes. And they share the 'oracle' account.

I am not putting this forward as the "best" idea by any means, but in context it makes sense. I've worked with both DBAs for years and we have a trust level that makes this possible. If I see something in /var/log/secure to the effect of 'sudo su -' or 'sudo bash' (yes, I read my logwatch reports daily) then we have a frank conversation about that.

---

Two things:

1. While I can't vouch for it (I've never used it) it sounds like the special shell proposed by unSpawn might be a good solution for you. If it works as advertised, that is.
2. As you can see, there are a lot of different ideas about how to approach this. To help narrow it down you'll need to provide more details about your application and your exact needs.

Yes, this is simple. Read the manpages for sshd_config(5).

If your DBAs only need occasional access, you could easily add and remove them from a group you create as needed. That group could be used then in a sudo statement. IMHO, your statement "I've worked with both DBAs for years and we have a trust level that makes this possible." is more significant than the sudo details.

Some of the details the OP gave hinted at root and system user ssh access, which in my mind is something of more importance than the "defective design" of sudo. A defective implementation of sudo is more likely. On the other hand, if you are too anal about security and make it very difficult for admins to work, or make them feel demeaned, the highly qualified ones who would never cause a problem will work for someone else.

I've got a strong feeling that Linux and some Unixes will be moving toward using PolicyKit. It still seems like a moving target to me. Still a lot to learn.

I am still here, thanks for all the helpful information. Let me better explain my situation which may help everyone who has been contributing to this thread understand how I should approach it.

Previously our home grown web server like application was running as root (yes that was a very bad idea) so we recently converted to it running as a user similar to the configuration used with Apache. At the same time the developers removed this security flaw, I introduced central authentication using LDAP. Prior to this everyone logged in using the same account and then had sudo -s, sudo su -, etc. access to the boxes. This access method was getting out of hand and since I was becoming the official network/Linux admin for the 50+ servers I needed to use tighter controls.

Since running our server as root was no longer allowed and all the directories, sub-directories and files under the files system for this service are now owned by this specific user (lets call it vision) I realized that I needed a way to allow users who now log in under their own unique user ID to become vision to perform the tasks associated with this service. The service looks for file/directory ownership for vision and any changes to this will break the service (like with LDAP for example). Since RHEL creates a group for every user added I did add the vision group as a secondary group to each user, however that doesn't help much when users start copying files within the file system used by the service, if ownership changes things break.

Once I figure out the proper way to provide users the ability to become vision, I need to make sure that the 20+ people who need access do not try to log in directly to the boxes using the vision user (which I know they will do).

So in essence I need to control access to the boxes (which I have done via LDAP) then allow the users to become the user vision to complete their tasks while preventing them from using the user vision as a back door since everyone will have the ability to assume this user.

I hope this helps better understand my dilemma, I am trying to introduce accountability and tighter control in an environment where it did not exist before.