/usr/lbin/ executables with suid bits

[G. Vrijhoeven]

Hi all,

In /usr/lbin you can find a the executables
/usr/lbin/chgpt
/usr/lbin/exrecover
/usr/lbin/protect_pty

The owner is root and the executables have a suid bit set on. I can not find any man page on the executables. Can S.O. tell me what the executables do and what the consequenses will be if the suid bits are be removed.

Thanks in advance,

Gideon

[Patrick Wallek]

If you remove the suid bits, then SAM will probably not function correctly. The executables in /usr/lbin are backend executables used by SAM for various things.

If you have an 11.11 system there will be man pages for some of the things there (modprpw and getprpw come to mind).

[S.K. Chan]

You are right .. all commands in /usr/lbin are not documented because they are not for regular use (ie not for the user to run from commnad line for example). What I know is in general they are used or called by some other command in /usr/bin for instance. Hence I would leave them untouched.

[G. Vrijhoeven]

Thanks for the input.

Patrick:
We have a policy that only the root user can use SAM. So if SAM is the only "script" that uses these executables the bit is not nessesary. My problem is that i have no idea what the reason is for the suid bit.


S.K.
Some commands in /usr/bin have suid bits of there own. Why these bits?

Gideon

[James A. Donovan]

Found this on chgpt

http://www.ornl.gov/cts/archives/mailing-lists/tru64-unix-managers/2002/09/msg00187.html

An internet search also turned up references to an overflow buffer bug in the Solaris /usr/lib/exrecover binary.

http://www.iss.net/security_center/static/5913.php

and a possible explanation of its function:
http://linux.oreillynet.com/pub/a/linux/2001/01/15/insecurities.html
http://www.lbl.gov/ITSD/CIS/faqs/UNIX_Faq/15.html

[John Palmer]

suid programs are fundamental to UNIX and are not a problem unless they can be overwritten by unauthorised users i.e. their permissions are wrong.

All the ones in /usr/lbin have write access to nobody so are not a problem.

The reason for suid programs...
Consider the passwd command, it has to write to /etc/passwd, /etc/passwd has permissions -r--r--r-- so can only by written to by root. The root suid program 'passwd' runs with an effective uid of root so can write to /etc/passwd.

Personally I'd leave the programs in /usr/lbin alone...

Regards,
John

[S.K. Chan]

Good question .. be it /usr/lbin, /usr/sbin or /usr/bin you would see some executables with SUID set the first time you install the OS. I can explain why .. in my own simple terms. Even though the executables have its suid set, most of the suid check is done within the compiled program. Meaning there may be certain functionality in the program that allow changes and even though suid is set at the file level, this does not mean the functions within the program adhere to the suid because it has the capability to use "setresuid" within it to perform further permission check. In other words, the suid you see does not mean the that everything or every functions in the executable inherits that.

[Bill Hassell]

It is never a good idea to try to 'improve' security for system programs by removing suid bits. They are set for a lot of reasons and since they are executables, they do not fall into the category of suid scripts. Removing these bits from programs in /usr/lbin, /usr/sbin or /usr/bin will destroy the system.

For instance, remove suid from login and no one can login. That's because you are nobody when login first starts, and once you have been authenticated, login has to have enough privileges to establish your session on your behalf. Similarly with mail tools which perform tasks in two worlds: system and user

So unless you want a very big job fixing your system, leave the /usr/bin, /usr/sbin and /usr/lbin executables alone. Now it is a VERY different story for /tmp, /var/tmp and /home. Those are directories where you do NOT want any suid executables since users can create files there. It is advisable to mount /tmp, /var and /home with the nosuid option. That way, if someone tries to circumvent security, the script or executable will not be allowed to run.

[G. Vrijhoeven]

Thanks all.

We are going the leave the bits alone.

I like to keep in mind the orailly statement on: ( thanks Jim)
exrecover
The recovery command for the ex editor, exrecover, has a buffer overflow. On many systems this program is unnecessarily suid root, opening up the possibility for a local root exploit. The problem is caused by not checking the length of the second argument.

There is no reason for this program to be suid, so remove its suid bit and update it to the latest version

This does not seem to be the case on HP_UX, is it?

Gideon