Changing root's shell from /sbin/sh
Robert Brockway
myself as an "old time" Sysadmin, although I am only 30. I take System
Administration seriously, regard it as a profession and expect a high degree
of professionalism and accuracy in my own work and the work of those around
me.
I follow much of the conventional wisdom surrounding Sysadmin, and understand
the reasons behind this wisdom. Examples of this would include putting the
FQDN before other names in the hosts file, and never changing root's shell.
Today, imho, the best way to admin a box is to keep the root shell
as /sbin/sh and use sudo to admin a box whenever possible (after using ssh
to get to the box). The only time you'll see me logging in as root directly
is on the console, and I'll only normally be there to perform low level
System Admin or in the event of a major problem.
Today I was contacted urgently and advised a very important app on a box
that I don't normally have much to do with was broken. The developers
had tracked the problem down to root's shell being removed. Some time in
the past an FM provider had changed root's shell to something they preferred.
They ceased to be the FM provider for the box & removed their directory and
took the root shell with it.
Fortunately one person who was on hand was in sudoers and I was able to
recommend that he sudo -s to get a root shell & edit /etc/passwd.
This was a totally avoidable situation. It is exactly for reasons like this
that I argue against changing root's shell. There is a Solaris root
shell FAQ here: http://www.roble.com/docs/sol_root_shell.html which
tries to say it is ok to change thr root shell but it fails to even
mention the folly in placing root's shell in a directory that might go
away some day (eg, /usr/local might be a seperate filesystem & get umounted one day).
This is a great page for discussion why _not_ to change root's shell:
http://www.cse.psu.edu/~groenvel/root-shell.html
So my recomendation, leave well enough alone & don't change root's shell,
use a nice tool likedo to give you better, safer access to superuser
privs.
Cheers,
-Rob
-- Robert Brockway B.Sc. Email: rob...@timetraveller.org
ICQ: 104781119
WWW: robert.timetraveller.org
Men are from earth. Women are from earth. Deal with it.
-wiseguy
news:10361188...@blake.timetraveller.org:
I sooo much appreciate your diligence and intelligence in this matter but
this issue is discussed almost weekly and ALWAYS generates so much
opinionated crap on this group that we should refrain from rehashing it yet
again. At this point, if someone is stupid to create a problem then they can
1) take flak from me online when they ask how to fix it, and 2) dig
themselves out of their own hole without any real help from me. There are
sooo many NT admins or even tech school flunkies who pretend to be UNIX gurus
out there that those of us in the know need to just let them suffer, unless
they ask a real esoteric question that actually piques our interest. As
screwed up as the field is, the days of free mentoring need to end.
--
-- Rob Prowel (A.K.A. da wiseguy)
URL: http://www.prowel.com/
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Robert Brockway
: DNS is a renaming virus.
: Do that in the hosts file, and .rhosts can stop working. Sheesh.
Well, can't say I've used a .rhosts file in some years :) Actually,
iirc .rhosts didn't trust dns and you _and_ to use the hosts file if you
wanted to get in without a password. I'd just like to say ssh-agent rocks :)
: Sharing root passwords with other admins, eh? ;-)
: That's a security no-no.
Not so. Normally there will only be 1 root password on a box (I don't like
multiple uid 0 accounts) and it makes sense for more than 1 person to know
the root password. See Truck number in the jargon file.
: Seriously, we had someone log directly in to root on the console
: in the computer room at a Fortune 100 company, screw something up,
: and they couldn't figure out who did it because of the shared
: root password.
This is unavoidable with the current unix security model.
You could apply the NSA patches to a Linux box to get rid of root I
believe but not sure this can be done on Solaris (I'd love to be
enlightened though).
: Keep working at your best practices...
Hmm...maybe you didn't read what I wrote :) I noted that I would normally
only log into a unix box as root on the console if there was a major
problem (typically because other access was impossible) or for major
system work (eg, something requiring a drop to single user).
Perhaps you're advocating to block anyone from _ever_ logging in as root
on the console. Again, outside the normal unix security model. I stand
by my best practice, thanks :)
Rob
-- Robert Brockway B.Sc. Email: rob...@timetraveller.org
ICQ: 104781119
WWW: robert.timetraveller.org
"Pleeeese God deliver me his arse"
--Mustosnuggs (seen during an online game of Britannia).
Akop Pogosian
> http://www.cse.psu.edu/~groenvel/root-shell.html
I am personally vary of sudo and -specially- of using it as a
replacement for root account because it uses your login password to
authenticate you. What if your password is stolen? (say, when you ssh
from a machine whose ssh has been replaced with a trojan binary that
records user passwords). Then they could login to the victim system
and with your password get a root shell. If you're using NIS or other
insecure directory service, then, this is equivalent of putting root's
crypted password in a NIS table.
Also, how does having to type "sudo" every time you need to execute a
command make your life easier? People who change root's shell probably
do it so that they end up typing less keystrokes not more. </rant>
--
Akop Pogosian
This space has been accidentally left blank.
Akop Pogosian
> Robert Brockway <rob...@avon.timetraveller.org> wrote:
>>
>> I follow much of the conventional wisdom surrounding Sysadmin, and understand
>> the reasons behind this wisdom. Examples of this would include putting the
> DNS is a renaming virus.
> Do that in the hosts file, and .rhosts can stop working. Sheesh.
>> Today, imho, the best way to admin a box is to keep the root shell
>> as /sbin/sh and use sudo to admin a box whenever possible (after using ssh
>> to get to the box). The only time you'll see me logging in as root directly
>> is on the console...
> Sharing root passwords with other admins, eh? ;-)
> That's a security no-no.
> Seriously, we had someone log directly in to root on the console
> in the computer room at a Fortune 100 company, screw something up,
> and they couldn't figure out who did it because of the shared
> root password.
> Keep working at your best practices...
It is possible to disallow direct logins to root using RBAC (root's
account is essentially converted into a role account). However, in
most sites, before I'd do it, I'd probably insist on creating a local
account (one that does not rely on NIS, NFS, or any other network
service being avalable) on each host for every system administrator.
Otherwise, no one would be able to get to root account in case of
network service outages and such.
Hansel & Gretel
"Akop Pogosian" <akopps...@ocf.berkeley.edu> wrote in message
news:apt9i6$1r03$1...@agate.berkeley.edu...
Hans Joergensen
> Today, imho, the best way to admin a box is to keep the root shell
> as /sbin/sh and use sudo to admin a box whenever possible (after using ssh
> to get to the box). The only time you'll see me logging in as root directly
> is on the console, and I'll only normally be there to perform low level
> System Admin or in the event of a major problem.
The only time i ever login on a box is to do upgrades, or
fix broken stuff... I don't really like sudo, because I
think it's unnesseary in most cases...
> Today I was contacted urgently and advised a very important app on a box
> that I don't normally have much to do with was broken. The developers
> had tracked the problem down to root's shell being removed. Some time in
> the past an FM provider had changed root's shell to something they preferred.
> They ceased to be the FM provider for the box & removed their directory and
> took the root shell with it.
The morale of this story could be, don't uninstall root's
shell, instead of don't change ... ;o)
Oh, and speaking of admin... Does anyone have any comments
on using cfengine to admin Solaris and Linux-boxes .. ?
It seems there site is about 10000 lines of text telling how
good cfengine is, and about 100 lines thats worth reading...
I prefer good old-fasion maintainance (combined with a
cvs-server for hosting my config-files, scripts etc.), but
some guy made my boss think that i should use cfengine...
--
Hans Joergensen, http://ph33r.dk
Photo-gallery @ http://gallery.nathue.dk