Impact?

[Dominick Grift]

On Thu, Apr 22, 2010 at 04:25:58PM -0400, m.roth at 5-cent.us wrote:
> I've got the java wants to write, and execmem errors. audit2allow gives me
> this:
> allow httpd_sys_script_t nfs_t:file { execute execute_no_trans };
> allow httpd_sys_script_t self:process { execmem getsched };
> allow httpd_sys_script_t usr_t:file { execute execute_no_trans };

label the target in this interaction (usr_t file) with type bin_t. You can find the location and/or the inode of the location in the AVC denial.
 
> 
> What would be the impact of implementing this policy on a server visible
> to the world? Would it open up some huge, known hole?

The impact would be that all generic httpd system scripts will be able to execute files with type nfs_t (nfs mount files) and run it in the callers (httpd_sys_script_t) domain.

By allowing the second line of policy you allow all generic httpd system scripts to execute anonymous memory and you allow then to set schedule on its own process.

info about execmem:

http://people.redhat.com/drepper/selinux-mem.html

The third and last rule signals a mislabeled file. You should label that file with the generic type for binaries (bin_t)
If you would allow httpd_sys_script_t (generic httpd system scripts) to execute files with type usr_t, then generic httpd system scripts will be allowed to execute generic files in /usr (not encouraged).

> 
>      mark
> 
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100422/154329fe/attachment.bin