MESSAGE
| DATE | 2005-05-23 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] su security
|
Multi-level 'su' access. Print
Posted By firstbase
Friday, 20 May 2005
For those of you lucky enough to use either Slack or
have a non-PAM-poisoned distro..I have some
suggestions for your 'su' configuration.
Most people don't appear to know/remember that 'su'
has a configuration file. This configuration file is
'/etc/suauth'. The /etc/suauth file can be extremely
useful in setting up additional security for 'su'.
Here, I'll show my own 'su' setup and explain how it
works as well as why I've done it.
First, when trying to set up security for anything,
make sure permissions are set properly for the files &
binaries involved.
Xires-at-System:~$ ls -l /bin/su
-rws--x--x 1 root bin 35780 2004-06-21 14:20 /bin/su*
Xires-at-System:~$
This is the Slack default. Generally, Slack is good
with it's setup of security, but for this..it's not
quite enough. We'd rather have '/bin/su' be
group-owned by group 'root' rather than by group
'bin'.
Xires-at-System:~$ sudo chown -c .root /bin/su
changed ownership of `/bin/su' to :root
Xires-at-System:~$
Next, we need to also check on 'sg'(which is part of
the same package as 'su'..but is for substituting
groups rather than users).
Xires-at-System:~$ ls -l `whereis sg | cut -d ' ' -f 2`
lrwxrwxrwx 1 root root 6 2005-03-16 19:58 /usr/bin/sg
-> newgrp*
Xires-at-System:~$
Here we see that 'sg' is a symlink to 'newgrp', so we
have to check it's permissions instead.
Xires-at-System:~$ ls -l /usr/bin/newgrp
-rws--x--x 1 root bin 19948 2004-06-21 14:20
/usr/bin/newgrp*
Xires-at-System:~$
Again, Slack has made the default group-ownership as
'bin'(which is normally fine). We'll change it for
our uses.
Xires-at-System:~$ sudo chown -c .root
/usr/bin/newgrp
changed ownership of `/usr/bin/newgrp' to :root
Xires-at-System:~$
Now to check the results.
Xires-at-System:~$ ls -hl /bin/su /usr/bin/newgrp
-rwx--x--x 1 root root 35K 2004-06-21 14:20
/bin/su*
-rwx--x--x 1 root root 20K 2004-06-21 14:20
/usr/bin/newgrp*
Xires-at-System:~$
Well, our ownerships are correct, but the permissions
got lost. Let's reset those.
Xires-at-System:~$ sudo chmod -c 4711 /bin/su
/usr/bin/newgrp
mode of `/bin/su' changed to 4711 (rws--x--x)
mode of `/usr/bin/newgrp' changed to 4711 (rws--x--x)
Xires-at-System:~$ ls -hl /bin/su /usr/bin/newgrp
-rws--x--x 1 root root 35K 2004-06-21 14:20 /bin/su*
-rws--x--x 1 root root 20K 2004-06-21 14:20
/usr/bin/newgrp*
Xires-at-System:~$
Alright, that much done..on to the configuration
files.
The /etc/login.defs file is somewhat of a 'master
control' file for many standard/basic/default
configuration settings. This is our first file to
modify. In this file, you should(hopefully) find the
'SU_WHEEL_ONLY' configuration option. This option
specifies that only those that are members of the
group with GID 0 may be permitted to use 'su' to
access root. Essentially, this means that on Linux
systems..you've gotta be in the 'root' group to "su
root". Ensure that this option is set to "yes".
While we're here, we should probably make sure logging
of 'su' and 'sg' is turned on. Options
'SYSLOG_SU_ENAB' and 'SYSLOG_SG_ENAB' should both be
set to "yes" and 'SULOG_FILE' should be set to a file
to log 'su' activity to. Other options to set would
be 'SU_NAME', 'ENV_PATH' and 'ENV_SUPATH'. A simple
"su" should be set for 'SU_NAME' and both both
environment path settings should be set
appropriately(as you would normally set any
environment path). A synopsis follows.
SU_WHEEL_ONLY yes
SYSLOG_SU_ENAB yes
SYSLOG_SG_ENAB yes
SULOG_FILE /var/log/sulog
SU_NAME su
ENV_PATH
PATH=/usr/local/bin:/usr/bin:/bin
ENV_SUPATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
Double-check your settings before you save the
file(trust me..a messed up setting here could cause
serious problems). The next file to edit is the
actual 'suauth' file.
The '/etc/suauth' file is, while being lesser known, a
relatively flexible configuration file for 'su'.
Within this file, you have a bit finer control over
who may access 'su' and whom they may substitute
themselves for. Lines within this file have a simple
format; ::. This should be made
more evident as we move through it.
Xires-at-System:~$ sudo cat >/etc/suauth
ALL:ALL EXCEPT GROUP wheel:DENY
Xires,patrix,liltoflm:ALL EXCEPT GROUP admin:DENY
Xires:ALL EXCEPT GROUP root:DENY
ALL:Xires:NOPASS
Xires-at-System:~$
Here's the translation of the above, line-by-line.
ALL:ALL EXCEPT GROUP wheel:DENY
This line essentially denies access to 'su' at all for
anyone who is not within the 'wheel' group. In order
to 'su' to any(denoted by "ALL") user, unless you're
in group 'wheel', you're denied access. This provides
us 1 extra level of protection for 'su'.
Xires,patrix,liltoflm:ALL EXCEPT GROUP admin:DENY
This line states that, in order to 'su' to users
'Xires', 'patrix' or 'liltoflm', unless you're in
group 'admin', you're denied access. Because this
line is AFTER the 'wheel' specification, these users
are give a second layer of protection. Now you must
first be in group 'wheel' to access 'su' at all, and
then group 'admin' to get to these users.
NOTE: The 'admin' group must be added manually! To do
that, use "groupadd admin" as root. Next you'll have
to add the user(s) to the new group. That command
should be "usermod -G admin ". To add the user
to multiple groups(like 'wheel' and 'admin'), use
"usermod -G admin,wheel ".
Xires:ALL EXCEPT GROUP root:DENY
This line specifies that in order to 'su' to user
'Xires', you must be in group 'root'. Given that this
line follows the previous two, this then adds a third
level of defense in 'su' access whilst still providing
full 'su' services. Remember too that we modified the
/etc/login.defs so that one must also be in the 'root'
group to access the 'root' user. Essentially, this
line and that setting are the same. Now, in order to
access either root or the 'Xires' account via 'su',
you must be in ALL of the groups: 'wheel', 'admin' AND
'root'. Of course, you'll also still need to know the
passwords to access the target account(thus providing,
perhaps, something of a 4th level of protection).
ALL:Xires:NOPASS
Since this is my personal box and, currently, I'm not
maintaining anything on it of interest to others, I've
provided myself with a little extra setting that
permits me to bypass any password restrictions for
'su'. Whilst technically this defeats some security
features of the system(basically, if anyone access the
'Xires' account on the box..they have full
access..even to root), it allows me convenience. As
well, after 16 years, I should be able to handle most
that people can send my way.
Testing! Isn't this the best part?
Xires-at-System:/$ su nobody
Password authentication bypassed.
nobody-at-System:/$ su
You are not authorized to su root
nobody-at-System:/$ su patrix
Access to su to that account DENIED.
You are not authorized to su patrix
nobody-at-System:/$ su daemon
Access to su to that account DENIED.
You are not authorized to su daemon
nobody-at-System:/$ su nobody
Access to su to that account DENIED.
You are not authorized to su nobody
nobody-at-System:/$ exit
exit
Xires-at-System:/$
Xires-at-System:/$ su patrix
Password authentication bypassed.
patrix-at-System:/$ su liltoflm
Password:
Sorry.
patrix-at-System:/$ su Xires
Access to su to that account DENIED.
You are not authorized to su Xires
patrix-at-System:/$ su root
You are not authorized to su root
patrix-at-System:/$ su
You are not authorized to su root
patrix-at-System:/$ exit
exit
Xires-at-System:/$ su
Password authentication bypassed.
root-at-System:/# exit
exit
Xires-at-System:/$
I suppose you can figure out how it all works from the
above.
This is, obviously, a work in progress..questions &
comments welcome here.
Credits are given Xires, one of our team members.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
