[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Permissions Required On hosts.allow ?



Jamie Heilman wrote:
> Joe Moore wrote:
>> As to your later message:
>> setgroups() and initgroups() are not necessary.  Already UID telnetd
>> is able to write to /var/run/utmp because of its membership in GID
>> utmp.
> 
> Huh?

Telnetd does not run as root.  However, it needs to write login entries into
/var/run/utmp.  How does it do this?  The UID telnetd is listed as a group
member of group "utmp".  The /var/run/utmp file is owned root:utmp, and is
group-writable.  in.telnetd can write utmp entries.

A simple extension of this principle says that if /etc/hosts.allow is owned
root:tcpwrap, and is group-readable, UID telnetd would be able to read it,
but most users would not.

>  
>>   If they run as a user not listed for tcpwrap (such as an interactive
>> user), they will not be able to read /etc/hosts.allow.  This may be a
>> very good thing:
>> 
>> If /etc/hosts.allow is unreadable, and /etc/hosts.deny has ALL:ALL,
>> tcpwrap will prevent all connections.  This is desirable if you want a
>> more secure system.  This means that if you have not added telnetd to
>> the tcpwrap group, in.telnetd will not accept connections from
>> anywhere, even if it's accidentally (or intentionally) started (by a
>> malicious? user)
> 
> !!!  Talk about a convoluted approach.  If you want services which
> happen to use tcp wrappers and which happen to have been started
> without your knowledge to reject connections by default just don't use
> wildcards (ALL:) in hosts.allow.  List every daemon explicitly.  Don't
> rely on the side effects of misconfiguration to do something that the
> framework already allows.

This side-effect is not a primary purpose.  It would be just as easy for the
malicious user to not link libtcpwrap.so into their executable.

> 
> I'll say this one more time: the system isn't that broken, stop trying
> to fix it.  There is no legitimate reason to jump through all these
> hoops just to hide your tcp wrappers configuration from your local
> users.  If the requirements for your host dictate minimal access
> rights use an access control system thats been designed to achieve it
> without creating a huge mess.

There may be no legitimate reason for _you_ to jump through these "hoops". 
However, there is at least one user who wants to hide his tcpwrapper config
from local users.  (The OP).

Unix groups are designed to achieve some level of access control.  They
don't require some special filesystem (with its own backup and restore
tools), or kernel patches.  If they are sufficient for the OP's needs,
there's no reason why they shouldn't be used.

--Joe



Reply to: