On Wed, 26 Apr 1995, Marcus J. Ranum wrote:
> This is what I call "practical testing" and it's based
> on intimate understanding of the O/S and a minimalist approach
> to relying on its features.
>
> Now, I did not go review the kernel code that implements
> setuid() chroot() and so on. That's for the trusted systems guys
> and you can see the impact that trusted system style assurance
> has on your product schedules.
>
> mjr.
To amplify what Marcus is saying (I agree with you, Marcus), there has
to be some trust in operating system services. One cannot test any
software and test OS services at the same time. The amount of testing
would not only be redundant (do you have to check chroot() for every app
that uses it?) but just about bordering on the rediculous--in the Real
World [TM]!
Sure there have been security holes "accidentally" built into OSes, and
some vendors seem to not want to respond quickly, if at all, to these
problems. But you can't go around with the fatalist attitude the OS is
buggy--unless it just happens.
That's righ, I did say "just happens." The setuid() and chroot(), for
example, have predefined behaviors. If these system calls fail to
perform as documented, then you can suspect the operating system. Not
before. I've lost enough hair over software to worry about the OS,
unless evidence points to OS services that are causing the problem (and
I've only found one in my career--so far).
When proving something, you have to have some items that fall in the
catagory of "fact." If you do not, you're going to spend a lifetime
proving what should have been given to you already. I would say OS
services are a given until evidence comes up that says otherwise--
especially given the complexity of OS'es today!
[Oh gee... I opened myself up to the "trust" vs. "security" arguments. :-)]
scott barman
scott @
disclosure .
com / barman @
ix .
netcom .
com
References:
|
|
