Re: procmail

[athan () mersinet co uk (Neil Soveran-Charley)]

 [ To moderator - Feel free to dump all but the 'fix' at the end, I'm
Bcc:'ing this to the person I'm 'replying' to.]

Dennis Simpson <dennis () bconnex net> wrote:
> Neil Soveran-Charley <athan () mersinet co uk> wrote:
> > 'ftponly' accounts, i.e. people grab email via pop, but also have ftp
> > access for maintaingin their web pages, with a 'shell' that prints a
> > message and exits, then the following is possible to work around such
> > security...
>
> What security?

  *sigh*, ok. The accounts in question are 'ftponly' as in they are
allowed (chroot'd to their home dir) ftp access for uploading files to
maintain the free web space they are given with their account. The
'security' mentioned was the fact their shell is NOT anything like
/bin/sh, but a small program I wrote that simply displays a message to
them, sleeps a configureable number of seconds, then exits. This message
explains to them why they cannot 'login' etc.
   FYI, this program is available at:

        ftp://ftp.mersinet.co.uk/pub/Unix/Utils/msgshell-1.0.tar.gz

Its easily configureable for any number of 'message shells', each having
their own message and delay time before connection is closed.

[snip me]
> If the account is locked, how did they create the .procmailrc?

   See above about 'ftponly'. Here the account is NOT locked, but
neither does it have 'normal' shell access. And remember, with the
'password' necessary to activate this, i.e. it doesn't happen for EVERY
email processed, indeed the subject could probably encode the display to
use as well, they could easily create this PRIOR to the account being
locked.
   A point to note if you DO have a shell server and sometimes have to
lock accounts. (chown ~<user>, their forward file and procmailrc etc to
'nobody' in the meantime, and chmod 000 their home dir?).

> If the account is ftponly, how do they get access to ftp to this
> obvious place for much more interesting mayhem than .procmailrc
> xterms?

   I think you got confused over what I meant by 'ftponly'. Did you
think it was anonymous ftp I was talking about?

> What security?

  See above (again).

> >   I'm sure procmail MUST have some security feature to disallow this
> > sort of thing? But I could be wrong, and haven't checked the manual
> > pages yet.
>
> What for? What are you asking procmail to defend against? The admin?

   It may be desireable to restrict the commands that can be run in a
procmail recipe, for whatever reason. This is the same reason that
sendmail has smrsh, and a similar optional 'solution' for procmail might
be a handy feature.

> If the customer isn't paying for a shell account, don't give them one.
> Point their home directory at something they cannot write, or something
> non-existent.

  But they DO need write access to their home dir. In fact that's the
only place they SEE when they ftp in (chroot/guestgroup feature of
wuftpd).

>               Or do it with their .procmailrc if they don't have write
> access to their home directory, but you do want them to have some
> standard procmailrc recipe (one unsuitable for a global procmailrc).
> Don't provide them with a shell.  If they don't need procmail, don't use
> it to deliver their email.

   True, and we DON'T give them a shell. I set up procmail so that
.forward doesn't need to be set for convenience. If I'd not done that
there would still have been .forward to contend with anyway.

> If you give them shell access to put up web pages, worrying about their
> being able to start an xterm this way versus another seems nonsensical
> to me.  I don't actually see why "shell access" is necessary for putting
> up web pages.  Why not let them ftp to their web page directories, but
> restrict their home directories (if they have one)?
>
> Am I missing something too simple here?

  Yes, the fact that ~<user>/public_html is where their web pages live.
I should have explained originally what I meant by 'ftponly' account.

  And now something other than my defending myself. The solution, whilst
still having the 'ftponly' accounts essentially set up the same way is
this:

        <create group 'internal', put everyone who DOES need to login
         to a real shell and do work in it.>
        mkdir /usr/bin/internal
        chmod 550 /usr/bin/internal
        chgrp internal internal
        mv /usr/bin/procmail /usr/bin/internal/procmail
        ln -sv /usr/bin/internal/procmail /usr/bin/procmail

You have to use a directory to protect procmail as it is setuid, and in
my case setgid (mail). I'm going to check if this is a 'bad thing(tm)'
and may change that, making the 'protection' simpler.
  I actually went a step further myself and have made all the 'bin'
directories only accessible to group internal. Watch out for users like
'news' and 'uucp, you need to add those to group internal too! Hopefully
this is a little extra protection against some future 'cracks', not that
I'll be resting on my laurels when it comes to security...

  In addition to this you can change in sendmail where the '.forward' is
located. I've changed used the following in the .cf file:

        OJ /mersinet/forward/$u

A directory that the users can NOT ftp into, due to the chroot to their
home directory. I made this directory mode 1777, and pre-created a
forward file for each user. Our scripts to add users create a forward
file on creation as well now.

-Neil
--
**************************************************************
* Neil Soveran-Charley, SysAdmin, Mersinet Internet Services *
* Email: athan () mersinet co uk    * "What? No quote?"         *
**************************************************************