Crispin Cowan wrote: > > Casey Schaufler wrote: > > >The shear cleverness of the capability+restrictive scheme > >is I believe its undoing. You can use it to totally circumvent > >the security architecure of the system. While it is fun to > >play with this sort of thing, I would never suggest using it > >for production code. > > > Hey, that's a neat come-back. You can use it to defeat any argument > (regardless of merrit) and it sounds way more intellectual than "so's > your momma!" :-) I'm sorry if it sounds that way. I'm trying really hard to come to grips with a Linux future based on restrictive hooks and it's not easy. I had a vision this morning of copying the entire security architecture into capable(), with historical checks left in place to placate inflexible maintaners and the security blob pulsing like an inflated silicon based creature from a 1950's Ed Wood movie. The C+R scheme circumvents the intention of the basic design, and while that would allow ACLs, it does so by deceit, not design. Stephen has convinced me that C+R can be used to do ACLs. I look at what it involves, and I say that I would not condone such in production code. I stick by that. If we have to do that to get into Linux, well, yuck, but it's not like I haven't seen other schemes just as convoluted. -- Casey Schaufler Manager, Trust Technology, SGI caseyat_private voice: 650.933.1634 casey_pat_private Pager: 888.220.0607 _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Nov 09 2001 - 16:32:48 PST