On Fri, 29 Jul 2005 23:32:01 EDT, Alain Reguera Delgado said:
> I've been stopped the web development. I feel selinux is a brilliant
> technology I'd like to implement in my webserver.
Actually, you have that almost totally backwards - SELinux is a brilliant
technology that gets implemented in the kernel to make sure it doesn't
matter *what* gets implemented in the webserver. Even if malicious code
gets control of the webserver, it still can't access anything the webserver
wasn't supposed to access...
Now, about the actual problem:
> Jul 27 15:41:38 hostname kernel: audit(1122493298.486:0): avc: denied
> { execute } for pid=4011 comm=httpd name=bash dev=hda5 ino=844138
> scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:shell_exec_t
> tclass=file
Unfortunately, this is *much* too big a can of worms to solve directly - it
would be technically possible to just add a rule that says 'httpd_t can
exec shell_exec_t' - but that would be a *really* *bad* idea because then
any exploit could get a shell (and exec_no_trans only partially minimizes
the problem).
Can you re-arrange the code so that /usr/sbin/sendmail gets invoked directly,
rather than via a shell? If so, then maybe we can add a can_exec of sendmail_exec_t.
Policy Gurus: How big a hole would adding a 'can_exec(sendmail_exec_t)' or
'domain_auto_trans(sendmail_t)' cause? And how many of these common "web interface
wants to send mail" problems would it solve?
Attachment:
pgpR1DqkyFq6c.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
