Re: NIS with local root

From: Kevin Jackson (kevin.jackson@genaware.com)
Date: 01/31/03


Date: Fri, 31 Jan 2003 19:24:48 -0000 (GMT)
From: "Kevin Jackson" <kevin.jackson@genaware.com>
To: <focus-linux@securityfocus.com>

If you mean from "if they have physical access to the box and are
determined, they'll get root anyway" you mean exploit some unpatched
service on the system -- then you may aswell forget about and type of NFS
"squash" option altogether! ...as we are in a different territory now.
See other securityfocus.com mailing lists on that one! ;-)

The "sqash" options solves alot of problems, but to answer the first
question fully (as opposed to my half-assed original!) then securing the
network and utilising some other type of NFS/Directory service is the
answer.

NFS/NIS _or_ Security. AFAIK, its always been the two options.

The problem in the first place was to stop normal users su'ing to root and
then being able to write files. Solved by root_squash.
But then of course, that person can su - user and then write files.

So the problem really resolves around a way of protecting root on the
local system AND still provide NFS-like mounting of remote directories.
These aren't answered by using NIS and NFS alone.

Kev

> In addition to the other examples people have given, think of a lab
> environment where untrusted users aren't given root... but of course, if
> they have physical access to the box and are determined, they'll get
> root anyway. I think this discussion is helpful; too many people think
> root squashing solves more problems than it really does.
>

-- 
Kevin Jackson
Systems Administrator                        Locate, Enquire, Empower
GenaWare Limited                              www.genaware.com
------------------------------------------------------------------------
PRIVILEGED - PRIVATE AND CONFIDENTIAL
This email and any files transmitted with it are intended solely for the
use of the addressee(s) and may contain information which is
confidential or privileged. If you receive this email and you are not
the addressee (or responsible for delivery of the email to the
addressee), please disregard the contents of the email, delete the email
and notify the author immediately.
Before opening or using any attachments, please scan them for viruses
and defects. We do not accept any liability for loss or damage, which
may arise from your receipt of this e-mail. Our liability is limited to
re-supplying any affected attachments.


Relevant Pages

  • Re: to allow root logins or not?
    ... Physical Access means, me being in very ... I recently did a clean install with root logins disabled. ... is passwordless BIOS setup, ... GAPING HOLE in theory on machine security as an attack on yourself. ...
    (Debian-User)
  • Re: security for a home system
    ... useless since physical access to the box means that they can get root ... You can make that tricky with a Master lock using the lock loop on the case ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...
    (Debian-User)
  • Re: Linux for Kids
    ... If he has physical access to the machine, he has root, although ordinary ... The situation with drivers hasn't improved much. ... It's better to build a whole new system, if you have the resources to do ...
    (comp.os.linux)
  • Re: Single User Mode and Root
    ... M> Ian Northeast wrote: ... M>>>> so that single user mode doesn't have root privledges. ... M> need root shell and they're known. ... You cant protect a machine from people with physical access. ...
    (comp.os.linux.misc)
  • Re: Ubuntu security hole? (not super major, but wondering if it is an issue to report)
    ... On Tuesday 09 May 2006 22:08, Mike Bird wrote: ... use removable media to become root. ... not booting off removable media. ... security because, given physical access, one could boot from ...
    (Ubuntu)