About Archive Tags RSS Feed


setuid/setgid binaries in Debian's Wheezy release?

7 June 2014 21:50

If anybody has access to a complete mirror of the Debian Wheezy release, and was willing to share a list of all setuid/setgid binaries that would be greatly appreciated.

It doesn't seem to be something you can find online, so you need to manually unpack each .deb file and look at the permissions.

I don't have access to a (complete) local mirror, and so I cannot easily build such a thing, unless I go to ebay and buy a random DVD-archive.

This list would be useful for folk wanting to direct their audits ..



Comments on this entry

icon Thijs at 09:02 on 11 June 2014

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.

icon Simon Paillard at 10:37 on 7 June 2014

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

icon Steve Kemp at 10:41 on 7 June 2014

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.

icon Evgeni Golov at 12:52 on 7 June 2014

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).

icon Steve Kemp at 13:14 on 7 June 2014

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.

icon Simon McVittie at 13:46 on 7 June 2014

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.)

icon Jakub Wilk at 16:54 on 7 June 2014

Lintian whilelists setgid games:

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

icon Evgeni Golov at 17:10 on 7 June 2014

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).

icon Steve Kemp at 17:12 on 7 June 2014

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.)

icon Colin Watson at 20:07 on 7 June 2014

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.

icon Bernhard R. Link at 10:37 on 8 June 2014

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.

icon Steve Kemp at 13:07 on 8 June 2014

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!)

icon Simon McVittie at 13:53 on 8 June 2014

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 uid1, 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