Through the setuid() and setgid() system calls, a person can get privilege which he/she does not have.
These systems calls can be executed especially in programs which have
the setuid or setgid bit set. A good example is the
passwd command through which a non-superuser is able to update the /etc/shadow file without requiring root privileges. Such
programs are setuid and setgid programs.
The ls(1) command on such files show the following
-r-sr-sr-x 3 root sys 9824 Sep 9 1999 /bin/passwd
The above is an example of a file with both setuid and setgid bit set.
Look for setuid and setgid files (especially setuid root files) everywhere
on your system. Intruders often leave setuid copies of
/bin/sh or /bin/time around to allow them root access at a late time. The UNIX find(1) program can be used to hunt for setuid
and/or setgid files. For example, you can use the following commands to find setuid root files and setgid kmem files on the
entire file system:
find / -user root -perm -4000 -print
find / -group kmem -perm -2000 -print
Note that the above examples search the entire directory tree, including
NFS/AFS mounted file systems. Some find(1)
commands support an "-xdev" option to avoid searching those hierarchies. For example:
find / -user root -perm -4000 -print -xdev
For good security on your host, try to have the minimum no of setuid
programs. If a setuid command is not being used you can
use chmod -s to remove the setuid and setgid bit both.
If you install SunOS5.7 with the complete OEM option, it comes with other packages like kerberos, gss etc.
I again copy the line from the entry in root file in cron
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
So even if you do have a valid setuid code, it automatically gets converted
to type data, as a find is made via cron for such
I wish to ask why only the c-shell was secured..ie.you can't execl("/usr/bin/csh",
"csh", 0); it says.. csh: permission denied.
Also if we could start something on kerberos(as it comes along with the OS)..it could be real helpful..
csh checks whether the real userid (getuid()) and the effective user id (geteuid()) return the same value. If not, it exits. So you can't execute csh this way.
I'm not sure whether you went thru the gsscred_clean script & the man pages of gsscred and gssd. They speak abt the Network security and not converting the setuid code to data.
To change an exec to data, you have to change the magic no. of the file.
For those who are new to GSS, it stands for Generic Security Service.
It is related to RPC authentication and provides a layer
between actual AUTH (eg. kerberos etc) and RPC layer. It is like PAM, that can use any underlying security system.
gsscred_clean is a script in /usr/lib/gss to cleanup the entries from /etc/gss/gsscred_db.
As of today GSS is used only by RPC apps.
Check your system binaries to make sure that they haven't been altered.
We've seen intruders change programs on UNIX systems such as login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync, any binaries referenced in /etc/inetd.conf, and other critical network and system programs and shared object libraries.
Compare the versions on your systems with known good copies, such as those from your initial installation media. Be careful of trusting backups; your backups could also contain Trojan horses.
Trojan horse programs may produce the same standard checksum and timestamp
as the legitimate version. Because of this, the
standard UNIX sum(1) command and the timestamps associated with the programs are not sufficient to determine whether the
programs have been replaced. The use of cmp(1), MD5, Tripwire, and other cryptographic checksum tools is sufficient to
detect these Trojan horse programs, provided the checksum tools themselves are kept secure and are not available for
modification by the intruder. Additionally, you may want to consider using a tool (PGP, for example) to "sign" the output
generated by MD5 or Tripwire, for future reference.
Do you have a UNIX Question?
Unix Home: Unix System Administration
Hints and Tips