[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-security-discuss
Subject:    [Security-discuss] how to prevent "su - <id>" from root
From:       mgerdts () gmail ! com (Mike Gerdts)
Date:       2006-04-21 5:20:52
Message-ID: 65f8f3ad0604210520p297ba168kd229118823b32d34 () mail ! gmail ! com
[Download RAW message or body]

On 4/19/06, Darren J Moffat <Darren.Moffat@sun.com> wrote:
> Wuming Shi wrote:
> > I'm in a NIS environment that a user can login to any machine with his
> > NIS account. So, the danger is that if one is the root on one of the
> > machines, he can "su - <id>" to become <id>.
> >
> > so, my questions are: how can I protect <id> on all machines? The
> > ideal solution should be have some configurations under this user,
> > allowing su from root to this user only one some specified machines.
>
> Until you stop using NIS forget about this risk there are so many other
> easy hacks.
>
> If you really want a more secure system and you want to protect against
> this risk you need to deploy BOTH LDAP over SSL for your nameservice AND
>   Kerberos so that you can protect your NFS mounts with sec=krb5p.

The fact that (workstataion) root is widely distributed to the user
community (and unlikely to change) says that at least desktop security
in the environment is already in pretty bad shape from a security
purist's point of view.  However most IT departments are not run by
security purists - they tend to be run by the type of people that
think that the use of Windows (with every user having admin rights on
desktops), Outlook, and IE are good ideas.

The thing that seems to be needing protection in this environment is
the integrity of the data on the NFS server(s).  So long as the NFS
servers use a a secure name service (e.g. /etc/*) and have a tightly
controlled root account, Kerberos could offer some protection against
rogue workstation users.  It still wouldn't be perfect, but there is a
different level of sophistication (and malice?) required to compromise
NIS than there is to use documented features of /bin/su.  This
configuration would be targetted at keeping the good guys honest. 
Adding LDAP+SSL would be a good next step to keep some of the bad guys
out too.

As an aside, it seems as though NIS could be secure if kerberos is
used (no crypt in passwd.* maps) and IPSec were used between the NIS
servers and between NIS servers and clients.  Is there some other
class of security problem with NIS that I am missing here?   (I
suspect that managing a large rollout of LDAP+SSL is easier than a
large rollout of NIS+IPSec, but that is not the point of this
question.)

Mike

--
Mike Gerdts
http://mgerdts.blogspot.com/

[prev in list] [next in list] [prev in thread] [next in thread]