-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Theo de Raadt wrote: >>I agree whole heartedly. It is interesting to see OpenBSD transition >>from a stance of "audit is the only way" to actually employing access >>control [...] > > I persist in my belief that policy-based mechanisms do not improve > security. If you cannot make a default policy that everyone can live > under, you are creating a trap: > > 90-99% of people use the default policy, because they do not > change it This has to be the golden rule of any functional security system. 99% of the admins aren't going to change the default system because 99% of the admins aren't the guys who wrote the system. In any moderately complex system the vast majority of the system administrators aren't going to understand every possible facet enough to be able to competantly make any large scale changes. > if that policy is restrictive, you have made a decision that > security is more important than useability > > if that policy is not restrictive, you have made a decision that > useability is more important than security Um, doesn't this kind of cancel out 8^) > (then there is also the issue of "it is restrictive towards what") > And that may be the beginnings of an important distinction. The security system needs to be flexible enough to support both the most anal (can only browse to single intranet site) and permissive (every desktop runs a quake server). [snip] > works?). I still believe very strongly that efforts directed at > "security technologies that only experts can use" matter far less than > "security techologies that invisibly improve everything". This is kind of the main point I was saying. A new security system can only improve overall security when it is widely deployed. The only way it will ever be widely deployed is if it's almost completely transparent to the end of the line admin who runs the system. Anything that requires complicated setup is a non-starter, no matter how good and secure it is. > > Hah, there is no public record to live down. Nor a policy change, > since we still audit code (with more emphasis on "audit means to > improve wholesale"). We also modify a lot of software for > priv-seperation or priv-revocation these days, to internally improve > specific application's resistance against successful exploitation (for > the situation of: it has a bug, but if you can exploit it, you gain > much less). Since we have more people interested in other areas, we > can expend efforts in other directions as well. This is all well and good, and I appreciate the efforts y'all have put in this area but I think there are more fundamental problems about how access controls are assigned that isn't being addressed by band-aid work like privsep. It would be nice, if possible given the contstraints I mentioned above, if the system's security archetecture could kill off the process when it is comprimised, rather than relying on the comprimise happening in a user-level privilidge section where it "shouldn't" be able to do _too_ much damage. It's a good solution that works with the system we've got, but I think there is a better solution out there somewhere. [snip] > the details of POSIX. Details matter more than anything else. Like a > gun, these things create an process environment which is "POSIX > maybe". Anything that requires a bunch of extra work from everybody (programmers, admins, etc.) is a no-go from the start. It's unfortunate that we can't completely start from a clean slate, but it just isn't practical. [snip] > If any security technology shows no success at finding other related but > minor bugs, I really just don't see the point. While this seems like a pointless and arbitrary distinction, it is kind of on the right track. Programs designed and implemented before $whizzy_security_system probably exhibit all sorts of ill behaviour that you'd never notice until the security system starts clamping down on it, catching bugs. More of a side effect than a main feature though, ISTM that whether this happens at all would depend on what kind of security system you are talking about. I don't think a security system _has_ to kick out bugs in existing software to be useful, but if it does kick out bugs it is evidence that you're on the right track I think. [snip] >>>Again, ISTM that the only way to get close to a reasonably secure system >>>is to only rely on the smallest, most audited codebase possible to enforce >>>security policy. [...] > > whenever I see the word 'security policy' everything after it starts to > sound a lot like 'blah blah blah maybe NSA or DOD will give me money' and > my brain fades out... > > (sorry, perhaps that is a little bit strong) Haha, no I wasn't trolling for DoD money I just mean "security policy" in the generic sense. These things (machines, programs, people) should be doing these things (talking to fileserver, sorting text, browsing web) and not these other things (scanning network, executing shells, reading accounting's files). I don't think that requiring each application to be responsible for its own security is ever going to work. It sure hasn't yet 8^) - -- Mark Tinberg Network Security Engineer SecurePipe, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE/QoTKFu7F5OUjbGcRAtL6AJ99RkKp4fMz7V8GDvmZRY0Yg2eWzgCfaeVx OxcYzC40Wh5z+G56zZy48nY= =DBFH -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Tue Aug 19 2003 - 13:55:32 PDT