Stephen Smalley wrote: >On Wed, 9 Oct 2002, Crispin Cowan wrote: > > >>That sounds kind of promising ... can you elaborate? I don't see how >>being able to mess with some other process's affinity does anything >>other than affect performance. How does this impinge on enforcing >>mandatory access controls? >> >> >I'm not sure that this is fundamentally different than the already >existing hooks on operations like setpriority/nice. In any event, for any >confidentiality policy (e.g. MLS), the affinity masks of processes can be >used as a channel to leak information in violation of the policy if we >cannot control setaffinity/getaffinity based on other security attributes >(e.g. the pair of MLS levels for the two processes). > I would avoid mentioning the covert channel. We have explicitly avoided providing any defense against covert channels. IMHO, it is hopeless to re-factor Linux to the degree necessary to even come close to closing covert channels. > For an integrity >policy, you want to be able to control the ability of a process of less >integrity to tamper with the CPU affinity of a process of greater >integrity, although the consequence may not be fatal. > This seems reasonable: appeal to the symmetry & completeness of hooking both nice and affinity, and point out that neither is on a kernel fast-path. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX http://wirex.com/~crispin/ Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html
This archive was generated by hypermail 2b30 : Wed Oct 09 2002 - 18:38:44 PDT