On Wed, 2007-11-14 at 12:03 -0800, James D. Parra wrote: > -----Original Message----- > From: Druid [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 14, 2007 11:57 AM > To: [email protected] > Subject: Re: [opensuse] limiting users who can use su > > > chown /bin/su binary so it can be only executed by people in a certain > group (by tradition, its usually called wheel group) > > Somewhere in this url it sasy how: > http://www.cromwell-intl.com/security/linux-hardening.html > > > On Nov 14, 2007 5:50 PM, James D. Parra <[EMAIL PROTECTED]> wrote: > > Hello, > > > > Is there a way to control which user accounts can use 'su' when using ssh? > I > > want only a couple of users to be able to change to root when using ssh. > ~~~~~~~ > > Perfect. Thank you. This is the kind of response I needed. > > For internal reasons, that I don't wish to go into here, there are uses who > get the root passwd from other users 'just becuase they needed to'. Again, I > don't want to go into details, however the above response will help be me > get around this problem. > > Many thanks and much obliged. > > ~James
I see some contradictions to what you say here. In your original post, you mentioned you did not want people to su from ssh. The solution presented limits su whether via ssh or on the machine physically. So if you're saying strictly limit su in an SSH situation, but allow in a physical situation, you haven't resolved the problem. The other issue here is that internally, you have people giving out root's password. Root constantly gets compromised when you do that. When something went wrong because "root" did something, how do you know which user actually played as "root"? A better solution would be to create a user or set of users who is a member of the root group. This gives you the added benefit of monitoring the "pseudo-root" user more easily through logging messages. With other tools, you can always configure the box to email you when "psudo-root" is on and performing what actions. And you can easily disable/delete that user on an immediate basis as needed. On the other hand, if you hand out root's password to everyone, and say someone in the company has been fired, you have to go through a whole process of notifying everyone else what root's new password is. There's that gap between termination and password change that allows a malicious ex-employee to continue their activities. Another solution is to avoid using passwords altogether in ssh by using authorization keys. This is a very simple solution to implement, and if you ban the use of passwords over ssh and use keys instead, you make your ssh session more secure too. In this case, you would place the user's public key in root's authorized_keys file. User logs into root via SSH with keys, and no password is ever submitted. Of course, the drawback here is having to clean up the authorized_keys file when necessary, and I'm not sure how to do that. Of course, there are several other solutions I can think of here using ssh with keys but I'm sure you get the drift here. -- ---Bryen--- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
