Re: Permissions Required On hosts.allow ?
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
Reply to: