suid conflicts from files where sticky bit is set Vs /etc/fstab

JockVSJock · 08-18-2015, 03:24 PM

I'm working with an Oracle DBA and we are trying to get Oracle Enterprise Manager to work by having sticky bit set on certain files.

There are a number of files that it needs to work with and the sticky bit is set on those files, and yet it still doesn't work.

Code:

[root@server1 bin]# ll nm*
-rws--s--- 1 root   dba 28087 Jun 21  2012 nmb  <---
-rwxr-xr-x 1 oracle dba     0 Aug 13  2009 nmb0
-rwxr-xr-x 1 oracle dba 28087 Jun 21  2012 nmb.0
-rwxr-xr-x 1 oracle dba  9755 Aug  7  2009 nmcbufp
-rwxr-xr-x 1 oracle dba 69611 Jun 21  2012 nmei
-rwxr-xr-x 1 oracle dba     0 Aug 13  2009 nmei0
-rws--x--- 1 root   dba 80525 Jun 21  2012 nmhs  <---
-rwxr-xr-x 1 oracle dba     0 Aug 13  2009 nmhs0
-rwxr-xr-x 1 oracle dba 80525 Jun 21  2012 nmhs.0
-rws--s--- 1 root   dba 34795 Jun 21  2012 nmo  <---
-rwxr-xr-x 1 oracle dba     0 Aug 13  2009 nmo0
-rwxr-xr-x 1 oracle dba 34795 Jun 21  2012 nmo.0
-rwxr-xr-x 1 oracle dba 32461 Jun 21  2012 nmocat
-rwxr-xr-x 1 oracle dba     0 Aug 13  2009 nmocat0
-rwxr-xr-x 1 oracle dba 55402 Jun 21  2012 nmosudo
-rwxr-xr-x 1 oracle dba     0 Aug 13  2009 nmosudo0
-rwxr-xr-x 1 oracle dba 21526 Jun 21  2012 nmupm
-rwxr-xr-x 1 oracle dba     0 Aug 13  2009 nmupm0
[root@server1 bin]# pwd
/ora/app/oracle/product/11.2.0/db_1/bin

[root@server1 bin]#

Looking around online, we noticed that removing nosuid for a directory under /etc/fstab and running

Code:

remount -o remount /ora/

Fixed the issue and now OEM works ok.

I'm not sure, because I want to set the sticky bit for various individual files so that the sticky bit is set only on those files Vs opening up for a whole partition and having the chance that there are other files that have the sticky bit set on them and running the risk that someone could do something bad against them.

So if someone could explain how the sticky bit works on a partition from /etc/fstab Vs individual files works...

thanks

jpollard · 08-18-2015, 08:51 PM

The fstab doesn't come into it unless the option nosgid is there.

And remounting doesn't do anything either.

OEM itself may have some internal checks that will do that.

JockVSJock · 08-19-2015, 05:58 AM

Quote:

Originally Posted by jpollard

The fstab doesn't come into it unless the option nosgid is there.

Then why have nosuid set there at fstab if it doesn't come into play?

jpollard · 08-19-2015, 06:47 AM

Quote:

Originally Posted by JockVSJock

Then why have nosuid set there at fstab if it doesn't come into play?

It is up to the administrator. setgid is considered a security weakness. For me, any filesystem that can be written to by a user should have several things disabled - setuid, setgid, nodev... Even if a file manages to get the flags set... they don't work.

In this case though, it wasn't indicated that it was disabled in the fstab.

BTW, it isn't called the "sticky bit" - that is a different flag with a different purpose.

JockVSJock · 08-19-2015, 09:15 PM

Quote:

Originally Posted by jpollard

BTW, it isn't called the "sticky bit" - that is a different flag with a different purpose.

Yes, your right. Thanks for correcting me.

So if suid, sgid, and nodev are security flaws, are these being phased out of Linux?

jpollard · 08-20-2015, 05:22 AM

suid, sgid, and nodev are there to provide security controls. All are used, but should not necessarily be available to general users.

As it stands now, it would be possible to eliminate devices from general filesystems - devices are supported by devtmpfs for most systems. Yet, some embedded will still use an ext[234] for /dev. And that prevents removal.

suid is used by administrators to provide access to privileged functions (such as password changing...) so it can't be removed from filesystems used for system binaries.... but that doesn't mean a user should be allowed to give away THEIR account to someone else... Same goes for sgid (used by some services to allow for shared locks, though that usage is fading).