Re: /etc/shells (was Re: procmail

[shaunl () MARCH CO UK (Shaun Lowry)]

Junya Ho <junya () fsdirect com> writes:

> Of course, it'd only be worthwhile if enough packages required the knowing
> of specific rights - pipes in .forward, .rhosts files, ftp access, shell
> access, ability to change shell & gecos info, ability to su &c.

I think you've touched on the problem with most of the solutions
sugegsted thus far - most of the services you're trying to restrict are
"third party" services, and are not provided by the kernel itself.  The
only thing standardised about theses services is their protocols,
implementations differ.  There's no reason an ftpd should honour a bit
set in /etc/passwd, and I can't  see a way for the kernel to enforce its
compliance.  This is even worse when you consider the number of
SMTP-compliant mail delivery systems you have to choose from on UNIX.

You can make the service implementations shipped with the OS compliant
to some sort of security ACL, but when you look at organisations with a
large number of differing UNIXes installed, one of the first things they
try to do is standardise mail delivery on them, i.e. rip out what's
supplied with the OS and install sendmail/smail/PP/whatever.

The only real solution available in the forseeable is to choose the
implementations of the services wisely, and configure them individually.
Central security admin of these services is restricted to file permissions
and port bindings on most systems.

        Shaun.

--
Shaun Lowry           | March Systems Ltd.,           http://www.march.co.uk/
PGP Key available     | 14 Brewery Court, High St.,
from key servers or   | Theale, UK. RG7 5AJ
via e-mail on request | +44 118 930 4224