Bugtraq mailing list archives
Re: procmail
From: athan () mersinet co uk (Neil Soveran-Charley)
Date: Thu, 8 Aug 1996 00:59:31 +0100
[ 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?" * **************************************************************
Current thread:
- Re: procmail Dennis Simpson (Aug 06)
- Re: procmail Jason S Kohles (Aug 07)
- Re: procmail Neil Soveran-Charley (Aug 07)
- Re: procmail Neil Soveran-Charley (Aug 07)
- Procmail, et al... Aleph One (Aug 07)
- <Possible follow-ups>
- Re: procmail Ken Robson (Aug 07)
- Re: procmail Rob Payne (Aug 07)
- Re: procmail Jason S Kohles (Aug 07)