Only use sudo

I am wondering what the easiest way for me to disable su and perform all root stuff using sudo, the way Ubuntu works. I am using a shared system, openSUSE 11.3, and notice that the only item that gets logged in su is who su’d. I need more information and sudo + command gets logged to /var/log/messages so I can see who did what and when.

How can I get openSUSE 11.3 to work similiar to Ubuntu when it comes to running elevated commands or editing files that a normal user doesn’t have rights to?

On 08/12/2010 02:36 PM, D8TA wrote:
>
> I am wondering what the easiest way for me to disable su and perform all
> root stuff using sudo, the way Ubuntu works. I am using a shared system,
> openSUSE 11.3, and notice that the only item that gets logged in su is
> who su’d. I need more information and sudo + command gets logged to
> /var/log/messages so I can see who did what and when.
>
> How can I get openSUSE 11.3 to work similiar to Ubuntu when it comes to
> running elevated commands or editing files that a normal user doesn’t
> have rights to?

You can rename /bin/su to something only you know, or change its permissions so
that only you can execute it. You could also delete it as long as you are
willing to never use su or switch to another console to do things when you need
to run as root.

These will, of course, only be cosmetic. As long as you have users with the root
password that you cannot trust, then your system is compromised.

lwfinger I don’t think D8TA want to delet su. I thik He just want to be abble to use sudo to do everything the root can do.

well… I don’t think it’s possible do “delete” root on opensuse, because it’s in the way ubuntu is build that there is defautly no root however it’s possible to let user do any “root needed” task with sudo, but you need to modify your "sudoer file and ass a group to the group list the user is part of.

so use as root “su -”

visudo

then edit the file like this (note that visudo have some verification presedure to ensure do something that break the sudo config, and that visudo use the vim editor.
I don’t know if you know how work vi (or vim), so I may put more info thant need.

so onse visudo is lanch go to the line like this and uncoment (by pressing delet when the cursor is over “#”)

# %wheel        ALL=(ALL) ALL

Also be sure there’s his line in the file (espesialy if there’s a line ALL ALL (ALL)=ALL

Defaults targetpw

there’s may be a coment with it…

if the line does not appear (you need to press i to get to the “insertion mode”, mode where you can insert carracter) add it to the file

Personnaly I set thos option in the sudo file

Defaults timestamp_timeout=0 #set time interval in minutes that sudo will ask for password, it must be an integer (0 mean every time 5 would mean 5 minutes
Defaults passwd_timeout=1 #set limit of time in minutes to enter the password must be an integer

Personaly I do set my timestamp_timout to 0. I won’t set the timestamp_timeout to a high number as it woul give an easyer acces to root an may be dangerous.
I’ve set the passwd_timeout option to be sure to not forget typing the passwornd and in case I forget it aumaticaly quit sudo after the set time.

Personnaly I’ve set some other options, if your are interest you may want to take a look at the man page “man sudoers”

once the change you want are done quit the insertion mode press the escape key. end type “:up” without the quotemark to update the file
and “:q” without the quotemark to quit visudo. (if there’s an error message it’s because you made a mistake in the file).

After having edditing the sudoers file you’ll then need to add the user you wisht to have acces to sudo to do “root needed” stuff to the wheel group with this comand:

groupmod -A <user_name> wheel

so nex time the user added to the wheel group will be able to lanch every program with sudo as root. Note that you’ll have to type the root password.

I have asked questions in discussions on these forums on this, You know what I decided su -

I agree personnaly I prefer to use su - (on my personal computer except for dayly updating), however it’s more secure to have a sudo well configured especially with HPC, where there’s 2-3 user that need to acces few administrative tool, 4-5 need acces to upgrading tools, but should’not be allowed to access root where there’s only “THE” HPC administrator that have to.

On 2010-08-12 23:06, bioinfo-man wrote:
>
> lwfinger I don’t think D8TA want to delet su. I thik He just want to be
> abble to use sudo to do everything the root can do.

Removing su would break the system,as many system scripts that run as root have to be able to su to
another user in order to run other things with lower privileges.

However, it should be possible to limit who can use su to root. I think it is done via pam, but I
don’t know how. And then, it is also possible to log in directly as root, so that possibility has to
be closed as well.

But another way, easier to do, is to hide root password, nobody knows it. It can be set by a
superadmin, a boss, or even somebody that doesn’t know how to use the machine; the password is kept
in a closed envelope kept in a safe, so that it can not be used unless there is an emergency.

> well… I don’t think it’s possible do “delete” root on opensuse,
> because it’s in the way ubuntu is build that there is defautly no root
> however it’s possible to let user do any “root needed” task with sudo,
> but you need to modify your "sudoer file and ass a group to the group
> list the user is part of.

Right.

In fact, the way “sudo” is set in suse is meant to be modified as soon as the system is configured.
If I understand it correctly, your method is set so that people on the group “wheel” can use sudo to
run any program, with their own password, no?

Yes, that is one way.

Another is, for example, to define people that can use tools related to mail, but not to apache.
Groups of tasks. This is quite complicated to setup, but I have seen it on some big machines.

One advantage is that the system logs any task that is run via sudo.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

I don’t like su - because it doesn’t log anything after the user su’s in /var/log/messages. Is there someplace else other than the bash_history that logs what the user who su’d is doing? The only thing that gets logged when a user su’s is su: (to root) root on /dev/pts/3 then after that I could add users/delete users, basically any and everything without anyone knowing since root is the “super” all powerful user. If I use sudo then that gets logged what commands are being executed by who. Granted su is much easier and I would prefer to stick with this method; however, it doesn’t provide adequate logging unless I am not looking in the right place or there is a way I can get that information logged.

On 2010-08-13 14:06, D8TA wrote:
>
> I don’t like su - because it doesn’t log anything after the user su’s in
> /var/log/messages. Is there someplace else other than the bash_history
> that logs what the user who su’d is doing? The only thing that gets
> logged when a user su’s is su: (to root) root on /dev/pts/3 then after
> that I could add users/delete users, basically any and everything
> without anyone knowing since root is the “super” all powerful user. If I
> use sudo then that gets logged what commands are being executed by who.
> Granted su is much easier and I would prefer to stick with this method;
> however, it doesn’t provide adequate logging unless I am not looking in
> the right place or there is a way I can get that information logged.

Well, the previous answers have told you where to look in order to disable su for most users. You
have to allow some uses, like root “suing” to another user, as the system scripts use this a lot.

However: modify sudo so that they don’t have to know the root password, or your efforts are moot.
And, remember that if a user can use sudo to do “anything”, they can edit the logs and remove their
own tracks. Just try “sudo xterm”. So, in order to be safe, you would have to explicitly list the
commands they can use sudo for, which is a pain in the backside for everybody.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

True and point taken regarding root and the root password. What I am looking for is logging. When using su - there is no logs of what is being done after the su: (to root) root on /dev/pts/3 entry. The user goes into stealth mode as root cause nothing is logged or does it and I am not looking in the right place? I understand this user could go in and clear up his tracks but that is not my issue nor concern as much as the events getting logged is. When using sudo I see who did what - kiosk : TTY=pts/3 ; PWD=/home/kiosk ; USER=root ; COMMAND=/usr/bin/xterm this user, kiosk, ran /usr/bin/xterm.

So completely disabling su is not good? I’ll try adding users to the wheel group as mentioned by bioinfo-man

Why not just set a secure password for root? perhaps also use tripwire?

We do have a secure password for root but multiple users access the machine which is done using AD authentication. Our process is a user logs into the server using their AD username/password and then today su’s and performs admin activities. My issue is that doesn’t log what the user is doing as root so I plan to use sudo since that does log what the user does, unless there is a su log that I am missing. We don’t have rogue administrators but for our internal auditing we would like to have logged what each user does and su doesn’t provide that, at least not from what I’ve found.

What is tripwire? Guess I’ll take a look at that as well.

iiWhat is tripwire? Guess I’ll take a look at that as well.

Tripwire is useful where there is a concern about system files for example being changed ,or a system being compromised, that does not seem to be the concern inthe case here though.

On 2010-08-13 17:06, D8TA wrote:
>
> True and point taken regarding root and the root password. What I am
> looking for is logging. When using su - there is no logs of what is
> being done after the su: (to root) root on /dev/pts/3 entry. The user
> goes into stealth mode as root cause nothing is logged or does it and I
> am not looking in the right place? I understand this user could go in
> and clear up his tracks but that is not my issue nor concern as much as
> the events getting logged is. When using sudo I see who did what - kiosk
> : TTY=pts/3 ; PWD=/home/kiosk ; USER=root ; COMMAND=/usr/bin/xterm this
> user, kiosk, ran /usr/bin/xterm.

I know.

> So completely disabling su is not good? I’ll try adding users to the
> wheel group as mentioned by bioinfo-man

It can be as simple as giving the root password to no one. But, then perhaps they can use sudo to
change it back.

You can, I think, restrict who can use su via pam. You will have to read the documentation on this -
I could give you a better answer if I studied pam myself, but that you can do yourself and save me
time :wink:


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

D8TA wrote:
> Our process is a user
> logs into the server using their AD username/password and then today
> su’s and performs admin activities.

are you saying you let normal users do admin activities?

and, since you mention AD i can only assume you mean normal Windows
users are given admin privileges on your Linux server…is that right?

may i ask what they need to do that they can’t do as a regular user??

tracking who does what by forcing sudo only gives you someone to blame
when the data and/or server goes poof…in my humble opinion it is
much better to not give anyone other than the actual administrator
the opportunity to blow away your server…

ymmv, but i’d look seriously at your current practices…


DenverD
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

On 2010-08-13 18:06, D8TA wrote:
>
> We do have a secure password for root but multiple users access the
> machine which is done using AD authentication. Our process is a user
> logs into the server using their AD username/password and then today
> su’s and performs admin activities. My issue is that doesn’t log what
> the user is doing as root so I plan to use sudo since that does log what
> the user does, unless there is a su log that I am missing. We don’t have
> rogue administrators but for our internal auditing we would like to have
> logged what each user does and su doesn’t provide that, at least not
> from what I’ve found.

Well, you just have to configure sudo so that, to do “sudo something” you have to use your own user
password, not root’s. This is what “bioinfo-man” explained how to do, if I’m not mistaken. It might
be possible to exclude some commands from the list, I don’t know. Or list what you allow them to do
(ie, you must exclude “su”).

Then, don’t give root’s password to anybody (keep it for real emergencies). Thus, even if “su”
exists, they can not su to root.

Meanwhile, I insist that you study “pam” so as to learn how to control who can su:


Elessar:~ # cat /etc/pam.d/su
#%PAM-1.0
auth     sufficient     pam_rootok.so
auth     include        common-auth
account  include        common-account
password include        common-password
session  include        common-session
session  optional       pam_xauth.so

I understand that your issue is accounting, not security.

> What is tripwire? Guess I’ll take a look at that as well.

That’s a tool to detect modification of system files by any source. It is used to detect rootkits
and other corruptions.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))