jeromie @
garrison .
com writes:
>> As far as being able to remove system calls from accessibility, I would
>>like to hear about if any firewalls have done this. Removing the system calls
>>from accessibility would limit potential vulerabilities.
And, bless him, Marcus responds with a box of band aids:
> It's not hard to do; you simply comment them out of the kernel
>or appropriately modify the kernel. I staunchly refuse to accept that
>these things are rocket science, or even very difficult; the kernel
>is just a program and if you are smart enough to use a system you can
>get source for then it's easy to fix. [fix details omitted]
About twenty years ago a pal got a job at one of the neighborhood
minicomputer manufacturers (there was one on every block back then)
and got into an argument with his boss, because he wanted to maintain
his own copy of the OS so he could fix "a few minor things" that
interfered with how he though things should work. Now, I didn't have
much experience with developing and maintaining a large, complex
software product back then, but even then I correctly predicted the
boss would throw him out of his office.
Sure, Secure Computing has created its own version of Unix. But this
is not, repeat *not*, a casual exercise. I agree it's not rocket
science -- rocket science is much easier than reliably manipulating
large software systems. The big difference is that the software rarely
distributes you across multiple counties when it blows up.
Regarding Marcus' specific example: chroot() is a pitiful thing. I
dislike any security mechanism that relies on an application to set
protections up correctly anyway. My readings also tell me that it has
subtly different properties on different Unix systems. So, a properly
chroot'ed program for one Unix might in fact be vulnerable on a
different one. And the list goes on.
> The *TRICK* is implementing the RIGHT code in the RIGHT
>place. For this example, if I put it in socket() - what about other
>forms of IPC? See - I'd need to be darn careful to cover all the
>angles. That's nothing to do with the formal properties of my
>protection model; that's a simple matter of Getting The Code Right
>and Damn The Formal Handwaving.
How does the poor sap know if the code is right?
This has *everything* to do with properties of the protection model, A
decent protection model can tell him if the kernel interface change is
likely to be correct or even adequate for the problem at hand.
Othewise you're just waiting for problems to emerge before fixing
them-- chasing the problems instead of getting in front of them.
People hate the Formal Handwaving because real systems are usually too
ugly and misshapen to make it worthwhile. And computer graphics was
difficult for toddlers before KidPix arrived. If the Unix kernel
interface implemented an adequate protection model for what we're
doing (it doesn't, which is why we put in TE) then the Formal
Handwaving would provide an obvious benefit.
There's also the whole question of playing fast and loose with the
Unix kernel interface -- what else breaks when you allegedly fix this
alleged security hole? Be sure to fix your kernel interface validation
suite when you change the kernel. And be sure your development team
all get updated kernel interface specs, and that they're WARNED that
their previous knowledge about the interface are no longer true.
> This whole game is about being REAL careful about your code.
>Whether it's code in the kernel or code in user space, it's just
>code. Because someone's waved the orange-book over the hacks they
>made to the kernel doesn't make them any fancier than the kind of
>hackery I described above (but for sure they're better documented!)
The Orange Book was written after security people spent several years
discovering that it's not enough to be careful about the code, not
even "REAL careful." Sure, it's obsolete in its current form and
implementation, but don't toss the baby with the bathwater. If you can
analyze something, you can learn something. The analysis doesn't give
you the Whole Truth, but it's valuable when it finds flaws.
And it does.
Rick.
smith @
sctc .
com secure computing corporation
|
|
