restrict suid and sgid permissions

[unixadmin_1]

The switch user identification (SUID) and switch group identification (SGID) permissions were still used. If an SUID program were to give users unintended write access, the system would be exposed as the SUID program could be replaced by a program with a different function and be used to gain unrestricted access to root. The use of an SGID bit creates a special program, allowing an otherwise restricted user to access certain files in a predetermined way.

[yulianto piyut]

check this site www.cisecurity.org

[Laurent Menase]

is it a question about the Set User ID bit? ( not Switch but Set)

If a non-root user modify a file with SUID bit, SUID bit & SGID (Set Group ID) bit is removed.

[unixadmin_1]

No its not the set switch userid and switch groupid

[Laurent Menase]

man chmod:
s Add or delete the set-owner-ID-on-file-
execution or set-group-ID-on-file-execution
permission for who. Useful only if u or g
is expressed or implied in who.

or

4000(= u=s)Set user ID on file execution (file only)
2000(= g=s)Set group ID on file execution (file only)
1000(= u=t)Set sticky bit; see below and chmod(2)

[unixadmin_1]

Can any explain better solution for this so that i can report the issue to senior admin

[OldSchool]

what issue (i didn't see one listed)???

what solution (as i didn't see one of those noted either)???

SUID and SGID bits on the the permissions set the user or group id to that of the program when it is run.

It appears that you may be looking at an auditors report, and they found some suid stuff they didn't like?

if thats the case, consider sudo or powerbroker to allow users access to the required resources. if its not the case, you need to clarify what your concern / issue actually is.

[unixadmin_1]

If i got a list how to restrict SUID and SGID for a particular userids

[OldSchool]

"If i got a list how to restrict SUID and SGID for a particular userids"

they are attributes of the file / executable. as such they aren't associated with a particular user. I don't know if ACLs will manage this or not.

the only way I know of it to keep the users out of groups that can actually execute the file in question and have it owned by someone other than the user you wish to exclude.

[TTr]

> If i got a list how to restrict SUID and SGID for a particular userids

You should install sudo and allow the list of userids to run whatever command with it. The suid and sgid of the command do not get affected.

[Laurent Menase]

there is RBAC on 11.31

else you need to make a program with setuid root, which test getuid() and if it matches with the allowed one, then allow it

An other way:
put the command you want in a directory only accessible from a group of users, then add all the users who have the right to use it in that group.

[Patrick Scherrer]

Are you on some sort of e-mail based job interview? You keep coming up with questions that seem obviously cut and pasted from a test or something.

[OldSchool]

" e-mail based job interview.."

if not that, then he's pulling issues directly out of a security audit or some such...

[TTr]

> e-mail based job interview?
> security audit

Or studying for a test and reading sample or previous test questions?

[unixadmin_1]

Company audit is going on but what exactly doe s the beloww sentence states...Its a urgent issue .please specify with solution and how to proceed...or else any thing related to sam


The switch user identification (SUID) and switch group identification (SGID) permissions were still used. If an SUID program were to give users unintended write access, the system would be exposed as the SUID program could be replaced by a program with a different function and be used to gain unrestricted access to root. The use of an SGID bit creates a special program, allowing an otherwise restricted user to access certain files in a predetermined way.

Recommended Action
The above list of programs should be checked to ensure that they are legitimate programs that require the powerful SUID privilege.

You should also check that:

1) Unauthorised changes have not been made to any of these programs;

2) The programs are being executed from the intended directories;

3)The associated Owner is appropriate and is not too powerful (i.e. does not have excessive permissions) for the program's function; and

4)The program's permission list does not allow write access to users who do not require it.

[Laurent Menase]

once again,
if a non root user modify a program with SUID root set, the SUID is reset.

[unixadmin_1]

Thanks a lot ..to me i just understood the concept but how to restrict this to few specific users...please send me the clear answer for this ..its a urgent issue...Thank you

[Michael Mike Reaser]

Only root can create SUID/SGID scripts owned and executable by root. So any "restrictions" on this capability would match the "restrictions" you place on access to a "#" root prompt.

[Laurent Menase]

# mkdir /myrestricted
# chown root:myrestrictedgroup
# chmod 550
# cp /usr/sbin/id /myrestricted
# chown root:myrest /myrestricted/id
# chmod 4550 /myrestricted/id

# grep myrest /etc/group
myrest::200:laurent

# su - laurent
$ /myrestricted/id
uid=250(laurent) gid=20(users) euid=0(root) groups=200(test)

# su - toto
$ /test/id
sh: /test/id: not found.
$ ls /test
/test unreadable
$

Does this answer to your question?

[unixadmin_1]

Hi Laurent please check the attachment

[unixadmin_1]

Hi Laurent please check the other attachment

[unixadmin_1]

Deviation:-
The following Audit Issues Identified by the Auditor General has still not been resolved:-

The switch user identification (SUID) and switch group identification (SGID) permissions were still used. If an SUID program were to give users unintended write access, the system would be exposed as the SUID program could be replaced by a program with a different function and be used to gain unrestricted access to root. The use of an SGID bit creates a special program, allowing an otherwise restricted user to access certain files in a predetermined way. (Refer to paragraphs 22 and 23 of the SekChek report.)

22 SUID Permissions.doc - Paragraph 22 of the SekCheck report resides within this document.
23 SGID Permissions.doc - Paragraph 23 of the SekCheck report resides within this document.

Urgent Request:-
Please can you load an emergency change to ensure that the system is in compliance by ensuring that:-

1) Review the list of programs with SGID and SUID Access.
2) Verify if access is applicable.
3) Restrict SGID and SUID Access from programs that do not require this access.

Please come up with best solution for the above and you can find 2 attachments

[Laurent Menase]

about 22:

If you cant to modify the rights of all those files, then you need to contact the various support:
HP support for /var/adm
/var/adm/sw/save.. are there to backup
previous patch state. So there is a solution which is to remove it doing a cleanup(1M)
side effect being to not be able to uninstall any patch there after.
about sw and vg, lvm commands you need to contact HP support if you want to remove SUID bit.

if you want to remove it from ping and traceroute and arp, then only root user will be able to use them.

The alternative to such thing is to use fine grain priviledge and RBAC.

about the fact to have write access on a SUID root file for others than root.
If this other modify that file the program will lose the SUID bit.
If you need an official statement of HP about that you will need to contact HP support.

For informinx files then you need to contact informix support.
but again even if a non root user write to it to modify it, the program will loose the SUID bit.


For AMMCATATLG it is not executable
- see the S and not s- so there is no problem.

only 1 file as other write access

[Laurent Menase]

About what is said in the document:
"If an SUID program gives unintended write access to users, your system is very exposed.
This is because someone could replace the SUID program with a program that has a different function to the original and use it to gain access to root at any time'.

Really I don't see how, because if that none root user modify that file it doesn't own, the file will loose the SUID bit, so it won't be of any use to gain any privilege.

example:
# cat yy
echo zzz>>xx
# chown bin yy
# chmod 6555 yy
# echo yes >xx
# chown bin xx
# chmod 6777 xx
# su lp
$ ls -l
-rwsrwsrwx 1 bin sys 12 Jan 20 14:28 xx
-r-sr-sr-x 1 bin sys 14 Jan 20 14:18 yy
$ ./yy
$ ls -l
-rwxrwxrwx 1 bin sys 12 Jan 20 14:29 xx
-r-sr-sr-x 1 bin sys 14 Jan 20 14:18 yy

[unixadmin_1]

Thank you very much for the response...May be your answer might be correct...as i am new to unix environment can you please explain how to sort out with each and every step...example i got access to informix and how should i proceed..i am totally new... from which directory i should start...rafsap> is root directory...so from there how do we execute the code mentioned...Please let me know