Some suggestions have been made above on how to arrive at at least some kind of initial list, which would perhaps need to be enlarged by doing codesearch for the right chmod patterns in postinst scripts; some manual work will in the end be involved so it makes sense to create the list one place and have it edited collaboratively.

I think the security tracker repository can be a good place for such a list. It could also be a good list for the hardened build flags effort to concentrate on; in parallel to any auditing going on.

See :
* http://lintian.debian.org/tags/setuid-binary.html
* http://lintian.debian.org/tags/setgid-binary.html
* http://lintian.debian.org/tags/non-standard-setuid-executable-perm.html
* http://lintian.debian.org/tags/setuid-gid-binary.html

Thanks for those links, they're moderately helpful but obviously not complete.

e.g. There's not a single executable listed there located beneath /usr/games, which holds numerous setgid(games) binaries.

do you have access to lilburn.debian.org aka lintian.debian.org? if so:

find /srv/lintian.debian.org/laboratory/pool -name index.gz | xargs zgrep 'rws'

should give a pretty good view on sid-(amd64|i386).

No, I'm not a Debian-developer, and so I have no logins..

I have recently re-considered re-applying, but I can't persuade myself I'd have enough free time.

Many setuid/setgid binaries are shipped non-setuid in the .deb and made setuid after installation, because they need to be setuid or setgid to a dynamically-numbered group, or only executable by a dynamically-numbered group. Unfortunately you can't find those except by analyzing postinst maintainer scripts.

(One example is dbus-daemon-launch-helper in the dbus package, which is setuid root and only executable by group messagebus.)

Lintian whilelists setgid games:
http://sources.debian.net/src/lintian/2.5.10.4/checks/files?hl=1097:1103#L1082

Besides, lintian.d.o tracks unstable, not wheezy. :-P

Here is the grep output: http://people.debian.org/~evgeni/tmp/setuid_binaries.txt

But Simon is right, many will be setuid dynamically (my example would be wireshark).

Thanks very much for that grep list, and if I miss a few due to dynamic changes then that's a reasonable way to fail.

(It's a shame there isn't a way of getting this information directly; but short of requiring manual updates to the control-file I guess it'll always be a bit hit and miss.)

Simon: IMO the proper way to handle that is to create the user/group in the preinst and ship it with its intended permissions in the .deb.

sgid games binaries is not something to waste audit power at. (Games are not done with security in mind and the whole process is only there to keep people from trivially cheating on highscores).

Looking in preinst/postinst for changing permissions will indeed be necessary. (Both via the proper dpkg-statoverride in preinst for dynamic users or via any chmod in postinst (if you find any chmod in postinst for shipped files, please also file a bug about that).

If you also have the newfangled "desktop" as target of your audit and you want some low-hanging fruit, auditing everything using dbus might be a way to go. It's often used as a way for privilege escalation and is usually written ignoring history thus repeating all the security problems of the past.

Games were some of my first targets, and they're still worth reporting and fixing, even if the real-world impact is minimal.

(Maybe I'm just biased because my siblings would fight with myself over high-scores - not a laughing matter!)

If auditing uses of D-Bus as Bernhard suggests, it's worth distinguishing between services exposed on the system bus (visible to all uids, is a privilege boundary, excellent target for auditing) and the session bus (only accessible by its own uid¹, not a privilege boundary unless non-default LSMs are used to isolate applications, should not be a high priority for auditing IMO).

One of the intended purposes of the system bus is to provide controlled privilege escalation, without every privileged service having to implement setuid correctly and safely. For instance, one of the features of NetworkManager/Connman/wicd/etc. is that desktop users can ask a daemon running as root to configure networking on their behalf, with policy in the daemon itself, /etc/dbus-1/system.d and/or PolicyKit determining whether the daemon will do as they ask.

[1] assuming there are no vulnerabilities in the dbus-daemon itself - please contact me privately if you find any of those