Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jan 1996 22:37:48 -0800 (PST)
From:      Nathan Lawson <nlawson@statler.csc.calpoly.edu>
To:        lists@argus.flash.net (mailing list account)
Cc:        security@freebsd.org
Subject:   Re: Ownership of files/tcp_wrappers port
Message-ID:  <199601250637.WAA13006@statler.csc.calpoly.edu>
In-Reply-To: <199601242145.PAA00691@argus.flash.net> from "mailing list account" at Jan 24, 96 03:44:59 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> In reply:
> > I think you misunderstand.  The PARANOID and RFC931 options can be added to
> > the hosts.* file to enable them, even if the compiled binary has them disabled
> > by default.  This allows you to use a stripped-down default version, but
> > upgrade it to as strict as you wish (even being stricter per service).
> 
> RFC931 can be faked out with almost no effort...  it's only legitimate 
> authentication use is over a TRUSTED network for casual identification of
> who is using a service, and even then....
> 
> ------ from RFC931.TXT --------------------------------------------------
[much off-topic info deleted]
> ------ End --------------------------------------------------------------

Uh, where did I say that _I_ wanted to enable ident checking?  Re-read what
I said above.  All I said was that you can compile one binary that can be
very permissive by default, but each system manager can add the flags into
a file to enable PARANOID or RFC931 as he or she wishes.  I did not make any
statements as to the merits of either of these options.

Like you say below, there are many different types of systems out there,
and each should have the option to enable whatever feature they wish (and
for whatever reason they have).

> > > Before we get over paranoid over security, lets us remember that the 
> > > primary aim of a base distribution is to provide an dynamic system, of 
> > > course minus the security bugs. 
> > 
> > Well, then FreeBSD has failed.  See the recent telnetd environment bug for
> > an example of this.  If you had wrapped telnetd and only allowed connects
> > from certain sites, you could have limited the scope of this vulnerability.
> > 
>> Bugs are going to show up no matter what.  If having the extra logging and easy
> > access control of tcp_wrappers at the installer's fingertips could have
> > prevented even one breakin, I'd be all for it.
> 
> the idea in computer security is not to be paranoid, that gets in the way of
> getting things done.  the idea is usually to use some common sense though.  
>such things as permissions alone can help thwart a hacker once he is in, making
> everything root:wheel when all that is needed is to remove the read bits from 
> a binary is stupid and potentially dangerous.

Huh?  So you are saying that making a binary unreadable is better than 
chowning it to root?  I'm sorry, unreadable binaries are security through
obscurity, while root ownership prevents a certain class of trojan horse
attack.  Which would you rather have:  an intruder get bin access and trojan
/usr/bin/login or have them break in and not be able to read /stand/ls? 

> as far as security packages, as i said before, you may like tcp_wrappers, i
> may do something different, and joe blow up the net may not do anything at all
> [to his demise]...  let's not standardize on anything in particular, just
> support as much as possible.

This is respectable.  Perhaps we can get the logging that the FreeBSD rlogin/
rsh support installed in the other network binaries as well.  How about
more example ipfw configs so that ipfw can be used as easily as tcp_wrappers
for first-time admins?

What I want is to get some kind of standard logging for all the network
binaries, and easily configurable access control for the entire distribution.

> > > IMHO, so long the base code is clean and no loopholes exist, it should 
> > > be good enough. Lets not blob the bindist further unneccessary...
> > 
> > Ok.  You can go through and prove all the code in FreeBSD and I'll look over
> > your results.  If you can't find any loopholes, but I can, do I get a free
> > lunch?  :)
> 
> AXIOM 1). Security holes will ALWAYS exist.
> 
> tell me how the lunch goes...

Well, you said above that "if the code has no loopholes, it's good enough
[and Nate's suggestions aren't necessary]".  I'm saying that it does have
loopholes (and you appear to be too), therefore your first statement is
not valid, and the code is _not_ "good enough".
 
> i know that i said this before, but i WILL say it again...  one thing i'd like
> to see is the majority of the binaries set to chmod 711 in the distribution.
> this is simple enough to implement, and should not harm the functionality of
> anything.

I think there is a small security gain from this, but not much considering
the availability of the sources.

-- 
Nate Lawson   \Yeah, I was dreaming through the 'howzlife', yawning, car black, 
Owner:         \when she told me 'mad and meaningless as ever...' and a song 
Cal Poly State  \came on the radio like a cemetery rhyme for a million crying 
University       \corpses in their tragedy of respectable existence.  - BR



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