>On 9 Aug 99, at 10:38, Ken Jones wrote:
> > The best solution i've seen is to group all the programs
> > that are possible security holes, like in.telnet and compilers,
> > to a new group. And only allow members of that group to execute
> > the programs.
> >
> > Just like all the suid programs should be grouped.
> >
> > It's a pretty standard security lockdown method.
The alternative is the reverse of that. Make all programs inaccessible and
selectively allow execute access to known good programs.
>What prevents me to upload binaries into my home
>directory/subdirectories, like ~/Maildir/tmp? (Other than carefully
>controlled ftp access?)
Some OSes support mount -noexec which means the OS will not run an
executable from that mount point. /home, /var and /tmp all are good
candidates for those systems that allow it.
Another option as someone alluded to earlier is to have a MAILHOME which is
where qmail looks for .qmail files. You can use qmail/users to define this,
then you allow very restricted access to that directory such that the .qmail
files are always in a known state. Typically this is done via a webpage that
has options like "Set forward" address, "Set vacation" and "set -address"
rather than "place data in a .qmail file".
Yet another option is to modify the shell so that it only allows execution
of certain programs/paths. I've modified bash and used it as a /bin/sh with
success in this sort of circumstance.
Yet another option is a one-line change in qmail-local to use a different
shell.
All of this is work, some of which requires real Sysadmin skills and real
programming skills, but the capability is there for those who want to bother.
Regards.
