Re: su change?

From: Matthew Emmerton (matt@gsicomp.on.ca)
Date: 04/04/01


From: "Matthew Emmerton" <matt@gsicomp.on.ca>
To: "Jeremiah Gowdy" <data@irev.net>, "Kherry Zamore" <dknj@dknj.org>, <freebsd-stable@FreeBSD.ORG>
Date: Tue, 3 Apr 2001 18:37:01 -0400


> > > if (!chshell(pwd->pw_shell) && ruid)
> > > errx(1, "permission denied (shell).");
> > >
> > > The only thing we need to prepend to this is a check to see if we are
> > trying
> > > to su to root, which we should allow regardless of the shell
specified:
> >
> > I disagree. The root account is an account that needs to have the
highest
> > number of security checks present.
>
> Then make a point as to why root, when not having a valid shell, not being
> able to log in is a useful security check in any way shape or form. So
> people can change root's shell to something invalid when they want to lock
> the root account ? That's nonsensical.

Last time I checked, only root had write access to /etc/master.passwd and
/etc/shells, so only someone who hacked root could change root's shell to
something invalid. (Note that I'm not handling the case of where an
administrator does something stupid.)

gabby# ls -al /etc/shells /etc/master.passwd
-rw-r--r- 1 root wheel 223 Jul 28 2000 /etc/shells
-rw------ 1 root wheel 1423 mar 18 14:10 /etc/master.passwd
gabby#

If someone happens to change root's shell, then the security of the machine
has been breached in some way. The immediate consequence is that root can't
log in. If you (the administrator) notices that you can't log in as root
anymore, then it's a really big clue that something major is wrong, and
would neccessitate taking the machine out of multi-user mode ASAP to perform
the investigation and fix things up.

Furthermore, if taking the machine down to single-user mode is a real big
problem (because it's a production machine or something equally important),
then the fact that someone's compromised root makes taking the machine down
a very reasonable thing to do.

The lesson? Don't screw with production machines unless you know the
consequences of your actions, and if you must screw around, make sure you're
using the appropriate tools (vipw, chsh, etc) to ensure that your changes
are valid.

--
Matt Emmerton
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message