[841] in linux-security and linux-alert archive
Re: [linux-security] Talk security?
daemon@ATHENA.MIT.EDU (Michael Brennen)
Mon Jun 24 14:58:32 1996
Date: Fri, 21 Jun 1996 17:24:42 -0500 (CDT)
From: Michael Brennen <mbrennen@fni.com>
To: Vaughn Skinner <vaughn@solid.net>
cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199606172040.NAA06715@arcott.mtjeff.com>
On Mon, 17 Jun 1996, Vaughn Skinner wrote:
> The most obvious thing /etc/shells is used for is nonymous ftp. You
> probably don't want to allow ftp access to this account. If you do,
> things get a lot more complicated. But don't forget that it's used by
> other programs too; for example, GNU su (a security hole in itself, for
> obvious reasons) allows the user to run an arbitrary program instead of
> the target user's login shell, if the target user is an unrestricted
> account (login shell in /etc/shells).
>
> So, to summarise, *don't* put an insecure program in a privileged
> position, and *don't* list a restricted shell as unrestricted.
>
> ......
>
> If it is a bad idea to put /bin/ftponly in /etc/shells, I need
> a new way to allow users to have ftp access without shell access.
>
> wu.ftpd requires the user's shell to be in /etc/shells.
>
> Is the solution a ftpd hack to accept /bin/ftponly as a valid
> shell? Is there a better way?
/etc/ftponly should not exist, and it does not have to exist. Make
/etc/ftponly as the shell in /etc/passwd and put it in /etc/shells, but
don't create it. It does not have to exist to use this as a login shell
for ftp. It doesn't work very well as a login shell if it doesn't exist.
I suppose some one could create it as a valid login shell; monitoring for
this might be prudent. Other than that it seems clean enough. Have I
missed something?
-- Michael
