Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!helios!auvc8!auvsaff
From: auvsaff@auvc8.tamu.edu (Dave Safford)
Newsgroups: comp.unix.admin
Subject: Re: Security in SunOS
Keywords: security
Message-ID: <12348@helios.TAMU.EDU>
Date: 19 Feb 91 15:29:18 GMT
References: <784@jt.dk>
Sender: usenet@helios.TAMU.EDU
Reply-To: auvsaff@auvc8.tamu.edu (Dave Safford)
Organization: Texas A&M UniversityIn article <784@jt.dk>, erl@jt.dk (Erik B. Larsen) writes:
Lines: 60

|>
|>I've noticed af security-hole in SunOS (maybe).
|>If you have a diskless workstation mounted on af server, and they are running
|>NIS, then of cource you only have one entry for root (on the server).
|>

NOPE: the client retains a distinct root, which must explicitly trusted with
a "root=" entry in the /etc/exports.  By default, remote roots are NOT trusted.

|>Now - everyone can boot a workstation up in single-user, and if you just know
|>a little bit of Unix, then it's easy to make an user called root or
something 
|>else in the clients /etc/passwd.
|>

NOPE: You can prevent users from booting single user quite easily - if
you remove
the "secure" flag from the console in /etc/ttytab, a root password will
be required 
to enter single user.  Note, this does not prevent the attacker from
booting another
remote kernel.  This can be prevented through the use of the new eeprom
security
mode, although it is not available on older machines.  The security mode can be
set to require a password to perform ANY rom monitor command!

|>Then you can boot up in multiuser, and you've free access on the server to
|>delete everything!
|>
|>Anyone, who know how I can solved this problem?

RTFM, particularly ttytab, exports, eeprom

|>I'll like to hear from you.
|>
|>
|>
|>Regards
|>
|>
|>Erik Bruijn Larsen 
|>Systemadministrator
|>Jutland Telephone Company
|>Denmark
|>Email: erl@jt.dk
|>
|>----------------------------------------------------------------------
----------
|>Remember: The Sun is always shining!
|>----------------------------------------------------------------------
----------
                              
The real NFS security problem, occurs when someone does manage to obtain
root on a client (despite ttytab, eeprom ...).  Even if root is not
trusted, root can su to any user, and access his files on the server.
Secure NFS was created to fix this problem, but unfortunately, secure
NFS isn't.
I won't go into details, as having discussed the problems with Sun at their
security BOF at the latest uniforum, they are aware of the problem, but have
no quick fix.