Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Nov 1996 20:34:32 +1030 (CST)
From:      newton@communica.com.au (Mark Newton)
To:        karpen@ocean.campus.luth.se (Mikael Karpberg)
Cc:        newton@communica.com.au, freebsd-security@freebsd.org
Subject:   Re: chroot() security
Message-ID:  <9611051004.AA21746@communica.com.au>
In-Reply-To: <199611050017.BAA17765@ocean.campus.luth.se> from "Mikael Karpberg" at Nov 5, 96 01:15:12 am

next in thread | previous in thread | raw e-mail | index | archive | help
Mikael Karpberg wrote:
 
 > > On the other hand, some kind of FAQ might be useful to make sure that
 > > people are aware of the potential that the presence of source code 
 > > provides for them.  If that's publicized then people are free to make
 > > their own hacks to enforce their own policies.
 > 
 > "If you can't write a UNIX on your own, you shouldn't use our's either"?

That's a rather extreme view, dear Sir -- I think both of us know that
what I said has born absolutely no resemblance to this rather incandescent
straw-man!

 > I think we should go the other way, making it easier to use FreeBSD.

By all means, and I think it *is* easy to use.  But we're not talking
about something the standard Windows 95 user will be utilizing.

Let's put this into perspective:  The applications in which that 
compile-time option will be useful are quite specialized.  To even
know that chroot() exists requires a certain amount of sophistication
as a user (let's face it, it is rather obscure, innit?).

Such a specialist application cannot be made foolproof.  Unfortunately,
if it's easy enough for unsophisticated users (let's call them "plebs"
or "peons" :-) to use then it stands a very realistic chance of lulling
them into a false sense of security... which is often worse than
no security at all.

We cannot create the impression that a four-line patch makes FreeBSD
"more secure" or "easier" because, put bluntly, it doesn't.  For the
overwhelming majority of users it'll make not a jot of difference;  for
those users who would benefit from the difference, they are hopefully
sophisticated enough to know that the four-line patch isn't the answer
to all their problems, and that they're going to have to invest a lot
of time with a lot of source code whether they like it or not.  

And, if they require the added security and can't comprehend the source
code then no accusations of intellectual snobbery will convince me that
they are the *wrong* people to be looking after their security.

Do you see my point?  While it's all very well to make FreeBSD so easy
that even a Win95 user can install it, it's something completely different
to announce to the world that it's so easy that a Win95 user can be
a security expert (god knows, we have enough NT advocates proclaiming
themselves to be security experts already! :-)

That is why I suggest putting it in the FAQ instead of putting it into
the source tree (if you really want to, the patch itself could be
put into the FAQ with the explanation).  The explanation in the FAQ
should make it clear that there is no such thing as a magic cure-all
for security problems, and if the user *really* wants security then
they should be using an air-gap firewall :-)

 > "We can not make FreeBSD perfect for all occations, so why even try?" is
 > not a good way to go, I think.

Again, you're drawing out a straw man attack.

I think we are trying.  I have a patch here which I'm testing at the
moment;  I'll release it to this list later tonight if I'm happy with
it.  As well as actual code, we're talking about putting something in
the security section of the FAQ and Handbook -- That's hardly "not
even [trying]."

We cannot allow people to think that they can solve all their security
problems and implement all their security policies without exposure to
source code, whether in the kernel or in userland.

 > The bloat is very small, and only a source-bloat. Not a kernel bloat.

:-) And thus UNIX grew from a system which would fit onto 20Mb of 
disk with complete source code into the system we all know and love
today <grin>

 > Hacking stuff in the kernel is much worse then crunching a userspace program
 > into exactly what you want it to. Things you do can affect stuff you didn't
 > even know existed, etc.

That's exactly what we want this one to do :-)

This is the kind of thing which is *intended* to break userland programs.
It's *intended* to reduce functionality.  It's a bit like removing the 
setuid bit from sendmail and running it as a non-root user:  It provides
a vast improvement in security for a severe degradation in functionality
(local users can't send and receive mail, in that instance, and you have
to run its "daemon" functionality out of inetd and cron).

In almost all cases, increasing security reduces ease-of-use.  It's
one of those trade-offs which has had commercial firewall vendors battling
with all kinds of user interface paradigms for years.  It's the kind of
thing that has left us entrenched with broken protocols like rlogin/rsh,
disastrously unsecure and yet so enticingly *easy* to use!  In general
terms, you increase the security of an existing system by disabling or
removing those parts of its functionality which are unsecure;  yes, there
are alternatives which preserve ease of use, but they generally decrease
maintainability, which necessarily decreases security.

I'm not a great fan of making security easy.  I'd rather make it secure.

I think I've been talking about two things -- Ease of making it secure
and ease of using it afterwards.  I hope I haven't obfuscated the issue
too much...

 > I for one would be very careful about trying
 > to add something like this safer chroot patch. And I wouldn't know were to
 > start. With the option in I can go in and change my config file and try the
 > default. If it's not exactly what I want, then I can look through the files
 > for code that has ifdef for that option, and I can read the FAQ entry, and
 > maybe dare go in and do a small change to that, in it self, small patch
 > (you (?) said it was, at least).

Ah.  So you're saying that if it was nice and easy then you'd go out of
your way to spend lots of time and effort on researching it before going
ahead and implementing it?  Excellent!  You have met the prerequisites for
using something like this.

Yet you expect those who don't meet the prerequisites to just add
"options FUNKY_CHROOT" to their kernel config file and "know" that
it'll make their system more secure without having the benefit of
knowing why?  Don't you see the dangers inherent in that approach?

 > Do you see my point?

Absolutely.  Do you see mine?

   - mark

---
Mark Newton                               Email: newton@communica.com.au
Systems Engineer                          Phone: +61-8-8373-2523
Communica Systems                         WWW:   http://www.communica.com.au



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