> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On Behalf Of Paul Robertson
> Sent: Wednesday, June 12, 2002 5:52 PM
> To: Ben Nagy
> Cc: [EMAIL PROTECTED]
> Subject: RE: firewall logging
> 
> 
> On Wed, 12 Jun 2002, Ben Nagy wrote:
> 
> > I don't think I have to go that far. I can probably subvert the OS 
> > through whatever the ultimate root account is, get the key from RAM 
> > and fiddle the HDD logs and then spam the flash log (multiple power 
> > events,
> 
> Sorry, you don't get the ultimate administrative role-

I _knew_ you'd say that. 

(For vendor boxes, the super-root password could just be a hash of
vendor-secret+serial number, so they can fix it if required. For ones
we're building at home, though, we have a problem. Is there a better way
than throwing away the super-root account at the end of the build phase?
And is there a way to enforce that? That would mean that for _real_
screwups you'd need to rebuild the box from scratch, but that's not such
a problem for mainly scripted installs - presumably the config files are
user-modifiable and can be backed up.)

>  guess 
> I omitted 
> that- the implementation I was working on was for an under 
> evaluation B2 
> (Red Book, not Orange) implementation. 

OK, does your box have per-app memory protection? If I have an account
that lets me add software components, can I add a dummy app that just
spits a complete RAM dump out to the network? Oh, and does the
memory-manager do memory scrubbing before it hands over new chunks of
RAM to each app? (In other words, can you do this in practice, not
theory) because otherwise I'll just fake it by malloc()ing until I own
as much RAM as I can and see what dirty linen I can get a hold of.

Of course if it _doesn't_ let me do this then it's probably mostly proof
against stack-smashing, which is a Good Thing (unless I can write back
into the app I just broke).

> > or lots of something else that's audited). Or I can trojan the app 
> > that reads back the flash log. You could stop this with the 
> BIOS, but 
> > then you can never legitimately upgrade your software. But 
> yes, we're 
> > being silly.
> 
> I think I can stop that with MAC or roles or a combination.

Well, signed/HMACed apps would stop me routinely modifying a running
app. If we're dealing with a vendor solution, then vendor could hold a
keypair and then sign all legit upgrades, and the firewall could be told
to only run signed apps. That needs to be supported in the kernel, I
guess. If we're dealing with a build-you-own, though, it seems to be
harder - we do need a way to add upgrades, and it _is_ something a
firewall-admin account needs to do.

[...] 
> > I'll believe it all when someone makes a firewall like 
> that, though. 
> > ;)
> 
> What would you pay for that?

Good question. Hopefully nothing!

> That's been the essence of my interest in RSBAC for the last 
> ~3 years...

I wonder if there's a simpler way to get the level of tamper-evidence
you want in the box...Probably not. We need the custom BIOS to stop
people booting a different OS. Without that you could turn these boxen
out as cheaply as any of the freeware firewalls, once all the work was
done. Hm.

> Paul

I've been thinking about my favourite way of running single-purpose
bastion boxes for a while, as well. It would be good if there was an
easy way for idiots like me to install a "DNS Relay Server" or "SMTP
Relay" (or even "Web Server") that would be akin to the OpenBSD ftp
install. Lots of people like to _talk_ about stripping down the kernel,
and running only essential components, and all that stuff, but I think
that time pressures mean that it gets "forgotten" a lot in the field. If
it's a box that only runs one app, then it shouldn't inconvenience
people to have a _really_ strong security baseline, and building on a
MAC/capability-based OS would be nice.

Once I get myself a lab and a decent 'net connection over here...

Cheers,

--
Ben Nagy
Network Security Specialist
Mb: TBA  PGP Key ID: 0x1A86E304 

-- 
Firewalls mailing list - [ [EMAIL PROTECTED] ]
To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html

Reply via email to