On Fri, 2005-07-29 at 23:56 -0400, Valdis.Kletnieks@xxxxxx wrote: > 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 One of the good things about SELinux actually is that it covers more than the kernel; e.g. dbus acts as a "userspace object manager" in concert with the kernel to secure the whole system. Similarly, there are patches for Xorg. I think it does make sense in some situations to patch the webserver. > 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). I don't see a problem with execute_no_trans; it stays within the httpd_t security domain. > 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? I think policy already has this as httpd_t has the privmail attribute, and policy grants: ./macros/program/mta_macros.te:63:domain_auto_trans(privmail, sendmail_exec_t, system_mail_t) My guess is all we need for this problem is: can_exec(httpd_t, shell_exec_t) -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
