Re: The Demise of Simple Assurance?

Previous message: jmjonesat_private: "Test"
In reply to: jmjonesat_private: "The Demise of Simple Assurance?"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

dawat_private

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