[TriLUG] to delete root, or not too?

[Aaron S. Joyner]

jason watts wrote:

>
>>> also, if root is deleted or disabled, dont you loose part of the 
>>> functionality of su ... the part where you just type su - and you 
>>> are now root, provideing you know the pw?
>>
>> It would appear so.  When I tried it on my munged up system just now, 
>> I got the old "user root does not exist" when I tried 'su -'
>> However, 'su - falseroot' still worked as expected.  Also, just a 
>> note in case you want to experiment, once I recreated my
>> root user, 'su -' worked normally again.
>>
>
>
> yeah, these were the results i would expect, cause the way i have 
> learnt it (self tought, not always acurate) is that su is for 
> switching users, and would thus point to root were the su - falseroot 
> knows who to log in as.
>
> _________________________________________________________________
> Try the next generation of search with Windows Live Search today!  
> http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline 
>
>
Philip and Jason's understanding is correct, Tanner's assertion that su 
is changing to UID 0 by default is incorrect.  The obvious reasons being 
two fold, first off su uses PAM, and the PAM module pam_unix requires a 
username to know which password to validate against.  More simply 
though, even if you didn't use pam, it's still got to know which entry 
in /etc/{passwd,shadow} to look at, as there can be more than one UID 0 
(also as previously discussed).

As for the merits of doing this, I think it's highly ineffective.  You 
should spend your efforts on hardening the system in actually useful 
ways, not ways that invite trouble and complacency through obscurity.  
Start by not allowing root's credentials to be used remotely by any 
service.  Typically, this would be actions such as setting 
"PermitRootLogin no" in /etc/ssh/sshd_config, or adding 'root' to 
/etc/ftpusers (restricts root from being used for ftp with some daemons, 
but you shouldn't be allowing ftp anyway), etc.  This makes knowledge of 
a user-level account required for all access to the system, so knowing 
the "root" username doesn't get you anywhere for a remote exploit.  On 
your typical Linux system (not going so far as to talk about 
super-hardened systems ala SELinux, GRsecurity patches, etc), any local 
user has to be able to read /etc/passwd, in order for commands like `ls` 
and `chown` to behave sensibly, so it's a given that they know a list of 
all users which have UID 0.  The further paranoid souls may wish to 
remove all users from the wheel group, enforce it's behavior (see docs 
on pam_wheel, implement for su), require all administrative actions to 
be done via sudo.  Lock root's password as Kevin suggested via `passwd 
-l root` (ideally now it should have to be `sudo passwd -l root`, do it 
that way to be sure you're not hosing yourself) then you're in 
reasonably good shape.

As for the suggestions to "remove" the root user, it's really a bad 
idea.  There are, unfortunately, quite a few things that make 
assumptions about the UID 0 user being named root, and not having a user 
root may cause some unexpected behavior.  Most of your main-stream tools 
will probably deal with it fine, but a few core tools which are typical 
to system administrators will get flaky.  `su -` is the prime example 
that comes to mind, but I would expect extended tinkering in such a 
system would bear out a few other unexpected consequences.  As a first 
place to look, the boot scripts may make assumptions that would cause 
you problems.  Should you truly want to go this way, it's a lot easier 
than you might think, though.  All you really need to do, is `vipw && 
vipw -s` or `vim /etc/{passwd,shadow}` and change the 1st field of 
what's probably the first line, from 'root:0:0:..." to 
"badidea:0:0:...".  The passwd and shadow files are the only 
authoritative source of any given user's username, and changing the 
username directly isn't that hard.  As a note, the group "root" will 
still exist, and you may wish to change it to match the new "badidea" 
name, or what ever name you choose to go with.

Another interesting note, is that on most *BSD systems, the root user's 
shell is csh.  This causes some pain for those people who aren't 
familiar with it, but since all the boot scripts are written in csh, and 
run with the root user's shell, you can't reasonably change it and then 
reboot the system.  So, there is another user, called 'toor', which is 
also UID 0, which has /bin/bash as it's shell.  The more astute reader 
has by no doubt already noticed that 'toor' is 'root' backwards.  This 
works quite well if you simply can't adjust to csh / tcsh as your shell 
when running as root on a *BSD box, with essentially no ill effects.  
Amusingly, you can also specify a separate password for this user, 
should you feel so inclined.

So in summary, explain to your TA that this is not Windows, and changing 
the "Administrator" account on the system doesn't make it  more secure.  
Even if it makes him sleep better at night, that's false security.  Most 
security compromises happen because a user has internal knowledge of the 
password (think disgruntled employee or ex-employee), and those users 
obviously know the username as well.  Most remote compromises which 
didn't involve prior knowledge of the system internally, are 
service-level compromises that give you a UID 0 shell or the ability to 
execute UID 0 code, not by way of guessing the username and password 
credentials (ie. buffer overflow in a service running UID 0, regardless 
if that user happens to be named root or 'badidea').  Thus, he's 
creating a headache for himself, and what ever administrator replaces 
him because he was fired for bad security practices after they got hacked.

Aaron S. Joyner