Nick Boyce wrote: > Yep - that's just the sort of thing I had in mind - I can't see a > problem with it if all the new GID does is grant read access to the > tcp wrappers config files. [ I just realized one more ingredient > required is to make the relevant service daemons sgid tcpwrap as well > as members of it. ]
Add water, makes its own sauce. > But I realize this stuff is tricky, and there may be some unforeseen > consequence that only a thorough knowledge of the source code (which I > don't have) can elicit - that's why I sought comments :) Its not that tricky, but its also not that broken. There are several approaches to system hardening. You can keep going down the path of absolutely minimal access rights, and eventually you'll end up with some sort of ACL system, and thats just fine, for the things that need it. There are several projects that do this, they all help make your system hard to crack/use/maintain, depending on your perspective. Wirex has something I that may or may not be called SubDomain, SELinux has some access control I believe, and there's probably others out there. And if you need to enforce a strict security model, these are probably the most apropos approach. What you're doing by creating a new supplementary group, is unnecessarily opening up a can of worms wrt the maintenance of your server. I would suggest that if you plan on participating in the active maintenance of your machine you should consider the value of simplicity over sheer paranoia. Lets assume you ignore me (which is just fine) and implement the supplementary group access control. Now to use tcpd, libwrap, tcpdchk, tcpdmatch, etc., a program's runtime privileges must include your supplementary group, or be those of the superuser. Obviously we can throw out programs that have superuser privs as having problems with this scheme. So you're left with the implication of a call to setgroups(2) or possibly initgroups(3), or it could mean the program is running with your new group as its primary group. Well running all your services with the new group as the primary one is going to be problematic. As you postulated not every service will work if you change its primary group, and perhaps more concerning is the amount of custom configuration you're going to have to maintain to set up a new primary group for a bunch of various daemons. On to the supplementary groups; both setgroups and initgroups require superuser privileges. Thus all services which want to use tcp wrappers must be started by a process with superuser privileges. Depending on which services you want to use this may or may not be an immediate issue. Services which require a privileged port usually already start as superuser so they probably won't be affected, provided they actually bother to call setgroups. I checked, and netkit-inetd does, so that clears you for everything that wants to use tcpd from netkit-inetd. (As an aside, the netkit-inetd shipped with Debian doesn't bother to check the !#$%ing return code though, which is lame, and incidentally, was reported over a year ago in bug #100186. If the OpenBSD inetd actually makes its way in as a replacement this issue, not to mention a host of other inadequacies, would hopefully be resolved.) Are there initially-privileged daemons which don't call setgroups? As I recall python didn't even support that syscall until recently, I'd say its possible this could bite you, though perhaps unlikely. As for programs which aren't initially privileged and want to use libwrap - they just won't work. (You may be surprised how many of those there are, use apt-cache to browse the reverse depends on libwrap0.) Keeping all this mind while you modify and update your server configuration over time, I mean hey, thats what makes this fun right? All that aside, if you run a fairly modest server without too many oddball requirements, you can probably make the supplementary groups hack work with relatively low pain. You've bought yourself a bit more maintenance overhead, and you haven't altered your fundamental vulnerability to compromise at all (by which I mean if the services you run and the configurations you run them with actually have exploitable bugs in them or not), but hey, at least your users won't be able to read those files. And thats, um, something. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
