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 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. You might wanna look at ALT Castle Linux, they seem furthest along. > > Once I get myself a lab and a decent 'net connection over here... If you want a decent 'Net connection, you're gonna hafta move north ;) Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." -- Firewalls mailing list - [ [EMAIL PROTECTED] ] To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html
