Dominick Grift wrote:
> 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:
<snip>
>> 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?
Um, let's try this again: Computer Associates, a mega-billion dollar
international software firm, was selling to mainframes decades ago, and is
*everywhere*, it's their product, proprietary, $$$$.
I've tried contact the folks that run the server at work who serve its policy
and license, and all they found was what I found via google, and I don't have
the authority to go talk to our CA account rep.
<snip>
>> 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:
<snip>
Thanks a *lot* Dominick - I've been on and off playing with this for months.
And it doesn't help that selinux *fails* to handle errors correctly - sealert
on these things claims setting httpd_unified on will fix it, and it does *not*,
so very clearly it's falling through to a false default error.
mark
--
A clear view of the libertarian view of the world: our lives are merely
capital's way of reproducing itself.
- whitroth, 2003
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
