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
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
