Check the permissions on the file -
ls -l /sbin/su
If you can not do that, check the permissions on the directory
ls -ld /sbin
Check for read - execute on both for world or group (group would be fine as long as you belong to the group). If the file/directory do not have r-x for group or world, then you cannot excute the program.
Configuring su for a user depends on the operating system. If you are using AIX these rights can be removed using smit. If you are using another system search the companies website for user properties or security settings. Most companies will give you some information, if not all, on how to control there system via the internet.
There are several Security software packages that will monitor unauthorized access to root user which will give email to root.
Also, I don't know what OS version you are using, but in HPUX, there is a config file that allows/restricts su rights, called scfmgr.
However, it is proprietary to HPUX only. Many versions of UNIX don't regulate the su command other than changing the permissions.
Just turing off su to all except root is sometimes impossible to do because some applications, ie Oracle, NetBackup, need su ability to get to root to execute some commands as root.
You will just have to protect the root password closely.
You guys gave me an idea with su, why let everyone run 'su' when only the users in the group 'wheel' should be able to run it.
I set su to the following permissions
(this is on openbsd 3.1 with a custom kernel)
I also had to chown root.wheel to allow people in the 'wheel' group to access 'su'. The default was root.bin.
Here are the following results;
uid=1004(taso) gid=1004(taso) groups=1004(taso)
bash-2.05$ su
bash: /usr/bin/su: Permission denied
and with a user in the wheel group;
uid=1000(crispexi) gid=1000(crispexi) groups=1000(crispexi), 0(wheel)
bash-2.05$ su
Password:
bash-2.05#
That may be okay for you. However, I only have 2-4 people who need su for root to my boxes. For me that is just one more file to manage which I don't have time to manage.
I can imagine one bad scenario. In an environment that allows users to have a regular password, that type of setup can be jeopardized to gain access to root, if someone gains access to another user's password. Also, I believe that granting group permissions are considered by some to be another possible security breach.
My situation is very restrictive, such that we use one-time password at the user level and less than 5 people have root su privileges, so I don't need to manage another file for only 5 users. Also, we have standards that don't allow us to change permissions on executables that can be considered a security hole.
How many people have root that you would need to create such a file? And why do so many people have root access?
root is privileged for a reason. I hope you trust all of those people implicitly.
The bottom line is if this works for you, great. Just remember, in most cases your scenario is not feasible.
>How many people have root that you would need to create such >a file? And why do so many people have root access?
only i have root and i didn't create any files i just modified permissions to 1 executable. You can't login as root remotley and i mostly login to that box remotley and only use it locally sparingly.
I use an AIX 4.3.3 box. root can only log in from the terminal.
The only way to get to root remotely is to log in using my id and su root. No other person can su root or log in to root remotely. With AIX there is an su log file that lists all attempt to su another id. When root logs in my ID is sent mail indicating the time and port of the login. Therefore I know if root is compromised. I then can search the su log files to see who attempted or sucessfully cracked my root password.
su has default of root.bin where i just chown'd it to root.wheel because i didnt feel like adding myself to the bin group heh
:o
there was no file creation, i just used chmod and chown everything else was left at default values