On Thu, Apr 22, 2010 at 05:24:48PM -0400, m.roth@xxxxxxxxx wrote:
> Dominick wrote:
> > On Thu, Apr 22, 2010 at 04:25:58PM -0400, m.roth@xxxxxxxxx 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.
>
> Right, *thank* you. Took care of both files (from rule one and three).
> >>
> >> What would be the impact of implementing this policy on a server visible
> >> to the world? Would it open up some huge, known hole?
> <snip>
> > 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
>
> Thanks, I'll look at that tomorrow (I'm getting ready to leave for the day).
>
> How about this one: we're stuck with CA's SiteMinder, and it wants,
> apparently, to rotate its logs. The AVC is
> type=AVC msg=audit(1271964387.568:10240): avc: denied { rename } for
> pid=7171 comm="LLAWP" name="smagent.log.69" dev=sda3 ino=46108075
> scontext=system_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:httpd_log_t:s0 tclass=file
>
> I'm in permissive mode on this box, but I've got several others that
> aren't. audit2allow gives me
> <snip>
> allow httpd_t httpd_log_t:file rename;
Well its probably better to write policy for the "LLAWP" application. Because by allowing these vectors you also allow
httpd this access and everything else that might run in httpd's security domain. (not just LLAWP)
But i can imagine that you may not know how to implement policy for it. Is this a redhat rpm?
Allowing httpd_t to rename files with type httpd_t is not such a big deal i believe. so allowing this shouldnt cause too much trouble.
> allow httpd_t java_exec_t:file { read getattr execute execute_no_trans };
This is your app (probably LLAWP executing java. If you would implement policy for your app then it wouldnt be httpd_t needing to execute this but your apps domain.
If you allow this then httpd and everything that runs in httpd's domain is able to run java.
Not really a big deal depending on that else your app and jva needs to operate since it will run in httpds sandbox.
> allow httpd_t proc_net_t:dir search;
> allow httpd_t proc_net_t:file { read getattr };
Thisi is probably your LLAWP app reading network state. If you allow this then you allow httpd as well as everything running in httpd's domain to read network state.
> allow httpd_t self:process { execstack execmem };
This is a pretty big deal execmem and execstack can cause buffer overflows i believe.
>
> Do I have mislabeled files there, as well; if not, would would be the
> impact of, say, the java rule, or the dir search rule?
Well except for the execstack and execmem the impact isnt so great. The problem is that by allowing it you broaden the httpd_t sandbox domain (you give httpd and stuff running in the httpd_t domain more access)
It would be best to implement a domain transition from httpd_t to whatever app needs this access (LLAWP?) This way you do not have to allow httpd_t this access but you can instead allow this access for your app alone.
That basically means that LLAWP cannot compromize the httpd domain.
But writing policy is not a trivial task. I would be willing to help write policy if that is at all possible.
I would need some information:
- Is is a redhat package (rpm?)
- Can you provide a rpm -ql of the package
- would you be able to test the policy and provide feedback?
>
> mark
>
> --
> selinux mailing list
> selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Attachment:
pgpX12y1B8XMm.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
