Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Jan 1996 15:18:26 -0800
From:      Lyndon Nerenberg VE7TCP <lyndon@orthanc.com>
To:        Paul Richards <p.richards@elsevier.co.uk>
Cc:        security@freebsd.org
Subject:   Re: bin owned files 
Message-ID:  <199601252318.PAA07296@multivac.orthanc.com>
In-Reply-To: Your message of "Thu, 25 Jan 1996 11:38:47 GMT." <199601251138.LAA24328@cadair.elsevier.co.uk> 

next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Paul" == Paul Richards <p.richards@elsevier.co.uk>

I am having a really tough time wrapping my head around this.

    Paul> Getting bin access does not give you root access.

and then

	 Therefore, the only
    Paul> way to get root access from bin is to replace, say, /bin/sh
    Paul> with a program that creates a suid root sh *when it is run
    Paul> by root*. 

Well, which one is it? Your own example completely invalidates
your first assertion.

If there is an implied "immediately" in "does not give you root
access," please say so. Your own example shows that bin access allows
root access. How quickly is based soley upon "bin's" skill.

    Paul> If you log in as root and don't realise that there
    Paul> has been a compromise of bin then that is your problem but
    Paul> in and of itself a bin compromise is safer than a root
    Paul> compromise for the reasons I previously explained.

What reasons? Again, Again I invoke your example above. How is this
"safer" than if the files were root owned?

    Paul> All other arguments relate to NFS and I refuse to even
    Paul> discuss NFS in this context. 

Why? If the argument breaks your proof, ignoring the argument does
not make your proof valid.

    Paul> If you crack root anywhere on
    Paul> an NFS system then the whole system is compromised and while
    Paul> making things owned by root makes it a little harder it is
    Paul> no protection.

I'm still not clear on why root ownership is "no protection?"

To my way of thinking, there is little *effective* difference in
actual security in the root-vs-bin ownership case, other than the
greater ease in attacking non-root files over NFS.

Someone else mentioned that bin ownership helped save administrators from
themselves. I invite any of you to run 'rm -rf /' under bin's uid (as
per the "accidentally chmod u+s a bin owned program" example given
previously), and tell us the results.

What all of this demonstrates is that having certain files owned by
bin gives you nothing more than a false sense of security.

I don't know the origin of the bin id. Can anyone out there state
*definitively* the reason for bin's creation? My gut feeling is that
it was created to make 'ls -l' look a bit prettier, and vendors have
been blindly copying the convention for years now without giving any
thought as to the real need for such an account. Things have changed
a lot since the days of seventh edition (or wherever bin appeared - it's
been around for as long as I can remember), and maybe it's time we
rethought the reasons for, and consequences of, a seperate bin id?

--lyndon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601252318.PAA07296>