Re: The Demise of Simple Assurance?

From: David Wagner (dawat_private)
Date: Tue Jul 31 2001 - 16:55:53 PDT

  • Next message: Crispin Cowan: "Re: The Demise of Simple Assurance?"

    Ok, this is a class of bugs that restrictive hooks can't help you with.
    Thanks for pointing this out!
    
    But I don't see any reason to panic over this.  There are plenty of
    other ways to shoot yourself in the foot.  Restrictive hooks are not
    a silver bullet; they reduce the likelihood of certain types of bugs,
    but by no means eliminate all possible coding errors.  Just because we
    can't solve all problems doesn't mean we should give up.  We should be
    careful not to let perfection become the enemy of progress.
    
    You mentioned two different issues.  Let's look at them one at a time.
    
    First, passing in a 'struct file *' to a hook.  Can we reduce the
    likelihood of a coding error by passing it in as a 'const' type?
    (Even if the typesystem doesn't enforce the requirement that you never
    write through a 'struct file *' pointer, it might still be useful to
    document that these are intended to be pointers to read-only objects.)
    
    Second, security_ops->bprm_ops->alloc_security().  Can we just document
    this as 'there be dragons here (treat bprm as immutable)', if there are
    only a few cases where this causes trouble?
    
    Of course, even if we can't fix either of these two issues, I still think
    there is value in the simple assurance properties of restrictive hooks,
    but if we can reduce the likelihood of encountering these new types of
    coding errors that you pointed out, so much the better.
    
    _______________________________________________
    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 : Tue Jul 31 2001 - 17:03:21 PDT