This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: Drew Bertola <drew@drewb.com>
Date: Wed, 7 Feb 2001 03:15:23 +0000 ()
To: Aaron Lehmann <aaronl@vitelus.com>
Cc: Drew Bertola <drew@drewb.com>, Wayne Earl <wayne@qconcepts.net>,
Subject: Re: [svlug] Security question: read-only drive
Aaron Lehmann writes:
> On Tue, Feb 06, 2001 at 08:19:28AM +0000, Drew Bertola wrote:
> > Not if the C code to control the switch is binary only (locally) and
> > protected by hardcoded password (argv[1]) with an algorithm like MD5
> > to keep it safe within the binary. (Not to mention the obscurity
> > involved).
>
> Bullshit. When you're root, you don't need those binaries to work for
> you to get hardware-level access.
>
> Even if you didn't know how the hardware stuff worked and the security
> through obscurity of the hardware interfaces was enough (which is not a
> good bet), you're root. That binary-only crap will not stop you. Simply
> disassemble the binary and change the MD5 comparison into a noop. It's
> not that hard. Security by obscririty gets you nowhere.
First you have to get root. That's the whole point. Ok, maybe as an
exercise there are whole's in this remote control thing. But
obscurity works in my favor here.
Remember, there's this real obscure way to control the read-only
switch which, lets say is listed as "/root/.ac_history". I don't know
why you'd bother to try executing it on a system to which you
illigitametly gained root access. Not to mention I've only executed
it via ssh and you need to know the password to get it to do anything.
Heck, I could even hack 'ls' so as not to list it. Not that I'd ever
go that far. But what are you gonna do, install a pristine 'ls'?
That's not something a bad guy normally plans on.
So, back to your first bit, you've broken in and gotten root. Aside
from the fact that it's not part of your m.o., you decide it would be
fun to start writing random bytes to i/o space? I bet you lock the
machine before finding the right byte and bit pattern to unlock the
drive.
Don't underestimate the power of obscurity. If your root password
wasn't obscure it wouldn't be much good.
===
Date: Tue, 6 Feb 2001 21:33:53 -0800 (PST)
From: "Dagmar d'Surreal" <dagmar@dsurreal.org>
To: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] Security question: read-only drive
On Tue, 6 Feb 2001, Rick Moen wrote:
> begin Dagmar d'Surreal quotation:
>
> > Yes, but anyone capable of running a gdb or strace will breeze right by
> > this type of check.
>
> One solution is to have out-of-band access. Dial-up, say.
I saw a little gadget on ThinkGeek this afternoon that allows remote
rebooting over an analog phone line, as well as a security code. It might
be modifiable to support such a thing as opening and closing a switch, but
then, using a removeable drive bay with a decent key lock in it probably
wins for time consumed.
> Out of band or not, any such setup has risks. The trick is to
> understand the threat model.
>
> > Beyond that it's a LOT of work for very little return unless you've
> > hardened everything else on the system and gotten every happy little
> > subsystem running chrooted and under restricted uids.
>
> Bah. Chroot is a thin reed on which to pin one's hopes. Not root safe.
It seems to be pretty safe provided nothing under the chrooting can regain
root privs.
===
Date: Tue, 6 Feb 2001 21:38:26 -0800 (PST)
From: "Dagmar d'Surreal" <dagmar@dsurreal.org>
To: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] Security question: read-only drive
On Tue, 6 Feb 2001, Rick Moen wrote:
> begin Dagmar d'Surreal quotation:
>
> > Filesystems you will need to keep writeable are /tmp, /var, and /etc (it
> > can be eliminated as writeable, but it's a major pain, better to rebuild
> > the important stuff so that it looks for it's configuration files in
> > *non*writable places other than /etc, like /usr/etc).
>
> Wrong. No.
>
> Look, you apparently don't buy into the basic concept of hardware-level
> write-protection combined with a mechanism by which the sysadmin can
> enable hardware write access on the fly. (I would have this be possible
> only locally at the physical box location, whereas Drew thinks it's
> possible to provide remote hardware-level write-enabling. He may be
> correct. It's a question of details.)
No, I don't buy into it at all.
If one goes to the trouble to make the media absolutely non-writeable to
prevent unauthorized changes even if the security model fails due to some
flaw, then I see no sanity in turning right back around and creating a
mechanism by which the media *can* be changed, protected by the same
_assumedly flawed_ security model.
===
Date: Tue, 6 Feb 2001 21:46:28 -0800
From: Rick Moen <rick@linuxmafia.com>
To: svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
begin Dagmar d'Surreal quotation:
> On Tue, 6 Feb 2001, Rick Moen wrote:
>> Bah. Chroot is a thin reed on which to pin one's hopes. Not root
>> safe.
>
> It seems to be pretty safe provided nothing under the chrooting can
> regain root privs.
Time for you to read the security history of chroot jails.
===
Date: Tue, 6 Feb 2001 21:48:58 -0800
From: Rick Moen <rick@linuxmafia.com>
To: svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
begin Dagmar d'Surreal quotation:
> No, I don't buy into it at all.
[...]
> If one goes to the trouble to make the media absolutely non-writeable to
> prevent unauthorized changes even if the security model fails due to some
> flaw, then I see no sanity in turning right back around and creating a
> mechanism by which the media *can* be changed, protected by the same
> _assumedly flawed_ security model.
The assumption in your concluding clause is demonstrably false, in the
context discussed: Please see earlier posts, as I have no intention of
revisiting them.
===
Date: Tue, 6 Feb 2001 22:05:25 -0800 (PST)
From: "Dagmar d'Surreal" <dagmar@dsurreal.org>
To: Drew Bertola <drew@drewb.com>
Subject: Re: [svlug] Security question: read-only drive
On Wed, 7 Feb 2001, Drew Bertola wrote:
> Aaron Lehmann writes:
> > On Tue, Feb 06, 2001 at 08:19:28AM +0000, Drew Bertola wrote:
> > > Not if the C code to control the switch is binary only (locally) and
> > > protected by hardcoded password (argv[1]) with an algorithm like MD5
> > > to keep it safe within the binary. (Not to mention the obscurity
> > > involved).
> >
> > Bullshit. When you're root, you don't need those binaries to work for
> > you to get hardware-level access.
> >
> > Even if you didn't know how the hardware stuff worked and the security
> > through obscurity of the hardware interfaces was enough (which is not a
> > good bet), you're root. That binary-only crap will not stop you. Simply
> > disassemble the binary and change the MD5 comparison into a noop. It's
> > not that hard. Security by obscririty gets you nowhere.
>
> First you have to get root. That's the whole point. Ok, maybe as an
> exercise there are whole's in this remote control thing. But
> obscurity works in my favor here.
>
> Remember, there's this real obscure way to control the read-only
> switch which, lets say is listed as "/root/.ac_history". I don't know
> why you'd bother to try executing it on a system to which you
> illigitametly gained root access. Not to mention I've only executed
> it via ssh and you need to know the password to get it to do anything.
>
> Heck, I could even hack 'ls' so as not to list it. Not that I'd ever
> go that far. But what are you gonna do, install a pristine 'ls'?
> That's not something a bad guy normally plans on.
>
> So, back to your first bit, you've broken in and gotten root. Aside
> from the fact that it's not part of your m.o., you decide it would be
> fun to start writing random bytes to i/o space? I bet you lock the
> machine before finding the right byte and bit pattern to unlock the
> drive.
>
> Don't underestimate the power of obscurity. If your root password
> wasn't obscure it wouldn't be much good.
I'm going to attempt to let this serve as my last comment on the matter.
What scenario you just described is a *fatally* flawed approach.
The intruder has gained root access, and your system is utterly unaware of
it, not only that, you seem to be unconcerned that the intruder has gained
unauthorized control of the system because you're counting on them not
being able to change the non-writeable filesystem to protect you. Making
the filesystem non-writeable doesn't do you much good if an intruder gains
control of the system and you a) don't notice or b) don't do anything
about it. Clearly they can still instruct the system to do whatever they
want. The one and only thing that it *can* do for you is prevent your
detection mechanisms from being tampered with.
...or to put it another way... If I gain control of a system that
happens to have most of it's filesystem non-writeable, it's only going to
inhibit my ability to do whatever I want with that machine by a very small
degree, and there are people out there who are a lot better at mutilating
carefully prepared security models than I am.
===
Date: Wed, 7 Feb 2001 09:40:22 -0800
From: Rick Moen <rick@linuxmafia.com>
To: svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
begin Dagmar d'Surreal quotation:
> I am aware you're arguing which sections of the filesystem need to be
> non-writeable. What I'm also aware of is that he appears to be trying
> to use a wrench to remove screws, i.e., forming a bad security model
> around the non-writeable filesystem.
This conversation has been a bit confused, but I perceive (from
reviewing the list archive) that you are right about that: Drew's idea
of using a _software_ switch ("in-band" with the system to be protected)
to toggle hardware-level write protection appears to fundamentally
compromise that entire effort. At which point, why bother?
So, your point is well taken.
===
Date: Wed, 7 Feb 2001 11:43:29 -0800
From: Rick Moen <rick@linuxmafia.com>
To: svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
begin Drew Bertola quotation:
> I guess your idea about not "in-band" control would be much better,
> but again, that really relies on obscurity (and again, that's not such
> a bad thing - in this case).
Um, not necessarily. As I said, any such mechanism entails risks, and
you just have to make sure you understand the threat model.
Imagine that you have hardware write-protection controlled by a box
accessible by dial-in line. Modification access to the protected
filesystems then hinges on the security of the dial-in line, which need
not be protected only by obscurity. Alternatively, if one implemented
my original suggestion, and had write-protection toggleable only via
physical access to the host's front panel, then remote intruders could
know _all about_ the front-panel switch, but be unable to subver it.
Of course, as Dagmar pointed out earlier, intruders might still be able
to subvert the running state of the machine, even if they could not
alter particular (vital) filesystems. So, you would have solved _a_
security problem, but would still have others.
===
Date: Wed, 7 Feb 2001 17:24:50 -0800 (PST)
From: "Dagmar d'Surreal" <dagmar@dsurreal.org>
To: Seth David Schoen <schoen@loyalty.org>
Subject: Re: [svlug] Security question: read-only drive
On Wed, 7 Feb 2001, Seth David Schoen wrote:
> Rick Moen writes:
>
> > begin Dagmar d'Surreal quotation:
> > > On Tue, 6 Feb 2001, Rick Moen wrote:
> >
> > >> Bah. Chroot is a thin reed on which to pin one's hopes. Not root
> > >> safe.
> > >
> > > It seems to be pretty safe provided nothing under the chrooting can
> > > regain root privs.
> >
> > Time for you to read the security history of chroot jails.
>
> I actually think you two are agreeing. Running non-root programs under
> chroot is almost pretty safe!
>
> Running programs that are or can be root or otherwise have privilege is
> probably not.
Yeah, I thkn yo might be right. Until the last round of problems swept
across BUgtraq, I was unaware that chroot() breaks so horribly when the
uid involved is root. After all the poking and prodding they did, I came
away with the impression that the function still works okay for non-root
processes, provided the daemon hasn't done a slipshod job of relenquishing
privs.
===
From: Drew Bertola <drew@drewb.com>
Date: Thu, 8 Feb 2001 21:33:34 +0000 ()
To: svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
/etc/mtab doesn't seem to work at all when symlinked from /etc. I tried.
I think that I'll partition the read-only disk with:
/boot 40MB
/bin 40MB
/sbin 40MB
/lib 100MB
/root 100MB
/usr/bin 100MB
/usr/sbin 40MB
/usr/lib 1000MB
/usr/src 1000MB
/usr/include 100MB
This uses a little over half the drive. Comments, suggestions, opinions???
===
Date: Thu, 8 Feb 2001 14:08:25 -0800
To: svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
From: Rick Moen <rick@linuxmafia.com>
begin Drew Bertola quotation:
> /etc/mtab doesn't seem to work at all when symlinked from /etc. I
> tried.
Well, that's why I said "_Try_ using symlinks." I had no idea if it
would work.
mtab is the last file Red Hat still has in /etc/ that ought to be under
/var/run. There used to be another one -- utmp? (Something else.)
They're that close to FHS compliance in /etc, but have been stalled at
that point for years.
You could recompile everything relevant, to relocate the file where it
belongs. Personally, I elected to use other distributions that take the
FHS more seriously.
===
Date: Thu, 8 Feb 2001 19:55:12 -0800 (PST)
From: Michael Higashi <mhigashi@hooked.net>
To: Drew Bertola <drew@drewb.com>
Subject: Re: [svlug] Security question: read-only drive
On Thu, 8 Feb 2001, Drew Bertola wrote:
> /etc/mtab doesn't seem to work at all when symlinked from /etc. I tried.
Depends on where you try to symlink it to. From man mount:
When the proc filesystem is mounted (say at /proc), the files
/etc/mtab and /proc/mounts have very similar contents. The former
has somewhat more information, such as the mount options used, but
is not necessarily up-to-date (cf. the -n option below). It is
possible to replace /etc/mtab by a symbolic link to /proc/mounts,
but some information is lost that way, and in particular working
with the loop device will be less convenient. Also, pathnames
containing spaces are handled correctly by /etc/mtab but not (yet)
by /proc/mounts.
===
From: Drew Bertola <drew@drewb.com>
Date: Fri, 9 Feb 2001 04:16:23 +0000 ()
To: Michael Higashi <mhigashi@hooked.net>
Cc: Drew Bertola <drew@drewb.com>, svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
Very useful and definitely worth a try. Now I just need to play with
a few other symlinks (sendmail stuff and ssh stuff), and I should be
able to throw /etc onto the read-only drive. Thanks Mike.
===
Date: Fri, 9 Feb 2001 01:28:38 -0800
From: Joey Hess <joey@kitenet.net>
To: svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
Rick Moen wrote:
> mtab is the last file Red Hat still has in /etc/ that ought to be under
> /var/run. There used to be another one -- utmp? (Something else.)
> They're that close to FHS compliance in /etc, but have been stalled at
> that point for years.
>
> You could recompile everything relevant, to relocate the file where it
> belongs. Personally, I elected to use other distributions that take the
> FHS more seriously.
You mean like Debian, which also has it in /etc? :-P
It's a rather hard problem. /var is the obvious right choice, but /var
might not be mounted yet when the mtab is needed. Linking to
/proc/mounts works, except for the bother with the kernel it not knowing what
device was mounted as the root filesystem (fixed if you use devfs), and
some sticky problems if you use loopback filesystems.
So in /etc it stays, for now.
===
Date: Fri, 9 Feb 2001 11:06:47 -0800 (PST)
From: "Dagmar d'Surreal" <dagmar@dsurreal.org>
To: Joey Hess <joey@kitenet.net>
Subject: Re: [svlug] Security question: read-only drive
On Fri, 9 Feb 2001, Joey Hess wrote:
> Rick Moen wrote:
> > mtab is the last file Red Hat still has in /etc/ that ought to be under
> > /var/run. There used to be another one -- utmp? (Something else.)
> > They're that close to FHS compliance in /etc, but have been stalled at
> > that point for years.
> >
> > You could recompile everything relevant, to relocate the file where it
> > belongs. Personally, I elected to use other distributions that take the
> > FHS more seriously.
>
> You mean like Debian, which also has it in /etc? :-P
>
> It's a rather hard problem. /var is the obvious right choice, but /var
> might not be mounted yet when the mtab is needed. Linking to
> /proc/mounts works, except for the bother with the kernel it not knowing what
> device was mounted as the root filesystem (fixed if you use devfs), and
> some sticky problems if you use loopback filesystems.
>
> So in /etc it stays, for now.
Now we begin to see why I spent four days anguishing over it myself before
cursing loudly and deciding that the stupid /etc could stay writeable if
it wants to *that* badly. Hehehe
===
Date: Fri, 9 Feb 2001 18:29:01 -0800
From: Joey Hess <joey@kitenet.net>
To: svlug@svlug.org
Subject: Re: [svlug] Security question: read-only drive
Rick Moen wrote:
> Indeed. That's why I said using distributions that take the FHS more
> seriously has its attractions.
A comment which continues to puzzle me. I just remembered the fhs has
this to say about mtab:
Required files for /etc:
o General files:
{ adjtime, csh.login, disktab, fdprm, fstab, gettydefs, group,
inittab, confissue, ld.so.conf, lilo.conf, motd, mtab, mtools,
^^^^
(And that's all.)
===