On 2012-04-02 18:28, Kees Cook wrote: > On Mon, Apr 02, 2012 at 11:25:26AM +0200, Niels Thykier wrote: >> No, At least the "hardening-no-stackprotector" can be triggered in a >> perfectly safe program where the stack protector is not needed. We >> worked around this in the test suite by ensuring there was a stack >> that needed protection, but I would be very sad to see people do >> the same in real programs. > > Well, I'd expect people to add an overrides file instead. >
Yes, but the tag will only be emitted on architectures that have stackprotector enabled - hench the override ought to be architecture specific. At the moment the user/packagers will have to keep that architecture list up to date in their override (or ignore it), and I feel Lintian would do a better job given we have the information available. >> If I understood you correctly in comment 44, then the protected >> functions could have the same issue: >> >> """ >> For example, if the only function used was gethostname(), it's possible to >> do compile-time verification to see that the _chk() version isn't needed, >> so even though the source was built with -D_FORTIFY_SOURCE=2, the >> unprotected function will be used. >> """ >> >> Actually, come to think of it - hardening-no-stackprotector smells a bit >> like a "wild-guess" since we can only say if it is safe, not if it might >> be vulnerable. Though "possible" -> "wild-guess" would change it from >> a "W" to "I" tag (and therefore not visible by default). >> The fortify functions code (in hardening-check) at least makes an >> educated guess and marks it safe if there are no uses of "possible >> vulnerable" functions (or if there are mixed uses). It may still be >> wrong, but we will not get a false-positive if the binary do not use >> any of the vulnerable functions. >> >> Do anyone have comments on dropping the stack protector to wild-guess? > > Based entirely on the language, it seems like the stack protector warning > really is "possible". It's not "certain", for sure, but it doesn't seem > like what I'd think of as a "wild-guess". In practice, if its behavior > is more like the "wild-guess" checks, then it would make sense to drop > it to that level. > Maybe - I do not code C if I can avoid it, so I do not know how common stack arrays are. This is partly why I tried to invovle others in the choice. :) > Perhaps we should examine some subset of the archive to figure out how > much noise these checks will add? > > -Kees > Perhaps - unfortunately, the Lintian infrastructure cannot do it for us, yet (see #660733). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
