Re: [patch] [sg]etaffinity hooks

From: Crispin Cowan (crispinat_private)
Date: Wed Oct 09 2002 - 18:37:27 PDT

  • Next message: James Morris: "[PATCH] allocation priority parameter for skb_alloc_security()"

    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 Cowan, Ph.D.
    Chief Scientist, WireX            
    Security Hardened Linux Distribution:
    Available for purchase:

    _______________________________________________ linux-security-module mailing list linux-security-moduleat_private

    This archive was generated by hypermail 2b30 : Wed Oct 09 2002 - 18:38:44 PDT