Future: fhs 2.3 compliance for fc3
Russell Coker
russell at coker.com.au
Fri Apr 2 06:42:35 UTC 2004
On Fri, 2 Apr 2004 15:22, Havoc Pennington <hp at 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
More information about the fedora-devel-list
mailing list