[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Future: fhs 2.3 compliance for fc3



On Fri, 2 Apr 2004 15:22, Havoc Pennington <hp redhat com> wrote:
> One setup would be that each user has an outgoing mail queue in their
> home directory, since homedir already has to be writeable by the user
> and gets backed up and so forth. Surely you could provide a
> /usr/sbin/sendmail that worked this way.

I'm not sure that the user should require write access to their own home 
directory, I can think of quite a few cases where denying such access is 
desirable.  But it's a reasonable trade-off.

The next issue is, how do we get the data out of the user home dir and send it 
via SMTP?  Do we have a system cron job that goes through user home 
directories?  If so we would have to make sure it changes it's UID to the 
user in question first so sym-link attacks against other users can't be done.  
We would also probably want to deny read access to sym-links in SE Linux 
policy.

If we don't have a system cron job we could have a script run on startup (same 
security issues as a system cron job) and have the "sendmail" program put 
itself in the background to keep re-trying the delivery.  Of course as 
sendmail will run in the user context a "slay" operation or a temporary 
problem (such as OOM) will inconveniently stop mail delivery for that user 
until the next time the machine is rebooted or the next time that they send a 
message.  So it seems that a system cron job to go through all users' 
directories is the best solution.

Another issue is what happens when the user runs out of quota.  We want the 
"sendmail" process to run in the user context on non-SE systems so it can't 
do any harm, but that means that it gets the same quota.  It would be 
annoying if the user ran a cron job which used up all their quota and then 
rendered itself unable to mail a warning message about being unable to work 
due to lack of quota...  Of course on SE Linux we can have a SUID program 
that is restricted by SE Linux policy, but we do want it to be reasonably 
secure on non-SE machines too.

I think that any solution along these lines will have some trade-offs, but 
they will be worth it for some users and it will be a good thing to offer.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]