On Thu, 13 Jun 2002, Ben Nagy wrote:
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?
I don't know of a better way than throwing it away (or only letting a
daemon use it during install, then having the daemon nuke it.) Given the
right audit role, that's independently verifyable BTW.
And is there a way to enforce that? That would mean that for _real_
Auditors, automation, checksums, etc.
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.)
Yeah, the last thing I was struggling with was how to distribute a
backup's encryption keys to a redundant or restore box in case of primary
failure (but that's because I was also trying to solve the multilevel
data which includes stuff the admin should never see problem.) I can't
seem to come up with a non-3rd party answer for that (though the 3rd
party could be another human-verified box.)
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's covered in Orange book even, object reuse is prohibited (yes,
there is actually some good stuff in the Red/Orange book stuff.) I'd
expect it to at least be enforced at the MAC compartment layer if not at
all layers.
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
No account would be given access to all of memory- that's where roles
really help for tasks versus a superuser account.
The other reason for Red Book is to control socket/network access.
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.
Absolutely you can expect a trusted system to do such scrubbing, though
cleaning keys up in memory is always a good idea anyway.
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).
I'd expect the enforcement mechanism to be a part of the TCB, and I'd
expect the TCB to arbitrate all accesses into it. I'd also put the system
level stuff into its own MAC, which would have read down into the stuff a
user could do- so it could accept requests, but nothing that wasn't a
trusted process would have access into the appropriate compartments.
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
MAC labeling will stop you modifying a running app.
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.
That doesn't need to be in the kernel- in my scheme it was done by a
package accepting daemon who trusted things signed by a root cert.- that
deamon had the role stuff necessary to run updating software and the MAC
levels necessary to add things to the TCB. The cert stuff was done at
installation, and that's the window of compromise oppertunity- but that's
a pretty narrow window.
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
Yeah, the LinuxBIOS stuff has been pretty interesting in that regard.
out as cheaply as any of the freeware firewalls, once all the work was
done. Hm.
It's a lot of work to do the initial architecture/configuration, but after
that it replicates very well.
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
