> You can look at this checker as essentially tracking whether the
> information from an untrusted source (e.g., from copy_from_user) can reach
> a trusting sink (e.g., an array index). The main limiting factor on its
> effectiveness is that we have a very incomplete notion of trusting sinks.
> If anyone has suggestions for other general places where it's dangerous
> to consume bad data, please send me an email.
I wrote something similar to this for userspace (via ld preload). Most of
my checks followed strings around and made sure they were length checked
so as to avoid stack overflows, but I also checked args to open, etc..
In your case, basically all destinations are trusting sinks at some level:
userspace gives you data to put it somewhere. You might want to instead
check that data is passing through functions that 'detaint', by checking
capabilities, etc. I bet that you'll find that something like 90% of code
paths are covered by a few common security checks. And that most of the
remainder could be rewritten to be.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/