security settings

[Brent W. Moll]

how do I set the following security settings on this file ?

-rwsr-s--- 1 root dba 2408432 Jul 22 12:53 dbsnmp

Thank you !

[Jannik]

chmod 6750 dbsnmp

[Steven E. Protter]

The command usually used is chmod for permissions, chown for ownershp, chgrp for group. chown can be used with the chown user:group format to change owner and group with one command/

Permissions should be:

-rwxr-xr-x

It should not have suid permisions set as it does now.

It should be owned by oracle or whatever user owns your oracle binaries. It would have been helpful if you'd said this was an oracle file.

fix:
chown oracle:dba dbsnmp
chmod u+rwx dbsmnp
chmod g+rx dbsnmp
chmod o+rx dbsnmp

alternate chmod
chmod 755 dbsnmp

SEP

[Ralph Grothe]

I have to agree to Steven,
and hope your words "security settings" were meant ironically.
You should keep the number of files owned by root and with suid or sgid bits set to an absolute necessary minimum on your systems.

[TwoProc]

I'm pretty sure that this binary was delivered by Oracle this was some time back. The current verions have this removed because (surprise) it's a security risk. From what I remember - they initially published a security bulletin telling you to address this manually (as you're doing now), but later they fixed the make file to do a chmod on it correctly.

The best way to get your stuff back to where it belongs when your Oracle binaries are messed up is to relink your binaries.

That being said - you'll want to review this file for permissions - it should be set to 750.

If you relink your Oracle_Home binaries and end up with the same issues - you should really think about upgrading the version of the database you're on, as well as keeping up with Oracle's latest security patches if you've not already done so.

At a minimum set the perms manually, and see if you can find it in the makefile and fix the chmod yourself.

[Shannon Petry]

Sometimes sticky bits are required for functionality. While security trends have gotten away from this as a mainstream model, many applications still use this model.

To add sticky bits, use chmod N+s where N is g(group), u(user), o(other).

I.E.

chmod 755 myprogram
ls -l myprogram
-rwxr-xr-x ... myprogram

chmod u+s myprogram
-rwsr-xr-x ... myprogram

I find it very irresponsible for anyone claim you should never have this bit set. Arbitrarily changing permissions on vendor binaries can often lead to application failure.

Even in HP-UX remsh requires a sticky bit to be set for root, as does uucp, yppasswd, and many more.

Follow vendor requirements for permissions, and if you feel something is insecure the vendor needs to address those issues.

Regards,
Shannon

[Gerhard Roets]

Hi

I do agree with Sharon about this one. In terms of the security settings. They key thing to remember about files with those permissions is that other people should not be able to modify the file or execution path. Hence the Group and Other write bits should be disabled.The necessary buffer overflow preventions must be in place( author/vendors task). The necessary signals should be trapped and handeld in a clean way.

With the above measures in place it should not pose a security risk. I did miss some statements but that is the key ones to look at. Part of the unix security model is to give you the ability to get elavated permissions and aboviously to have it removed later on.

Just my thoughts.
Gerhard

[Ralph Grothe]

Not to appear being pedantic,
but the sticky bit is something completely different, whose days I think have almost been counted because it used to serve "sticking" pages in memory once upon a time, when memory managment was handled differently.
Because of its loss of relevance nowadays its only purpose left seems to use it on directories to prevent users from manipulating files belonging to others in world writable directories, such as /tmp

The dangerous bits this thread is about are the setuid and setgid bits (or short sbit) that are named after the namesake syscalls.

Although this is a little digression from your problem you could also have a look at this document, which despite its age still has a lot of valuable suggestions how to "harden" ones system

http://hyatus.dune2.info/Unix/bastion11.html

[Geoff Wild]

The real standard now is to use symbolic mode:

So, to add setuid - chmod +s
to add setgid, chmod +g

man chmod for more info.

Be absolutely sure if you want setuid as root...

Rgds...Geoff

[Andrew Cowan]

I agree with Ralph about the "sticky bit". IBM nows calls it the "Save Text" bit as its only effect is when it is set on a directory.
Directories with this attribute mean that files created within it either can only be deleted by root or the user that created it, or when on a group the file will belong to that group regardless of the group membership of the user that created it.

[Jack C. Mahaffey]

I posted a script named 'getchmod' in the past. See if you can locate the script. This script will list the chmod settings that can be used to reset the permissions.

jack

[Pete Randall]

Brent - and Jack,

Here is Jack's "getchmod" script.



Pete