Impact?

[Dominick Grift]

On Thu, Apr 22, 2010 at 07:25:33PM -0400, mark wrote:
> Dominick Grift wrote:
> > On Thu, Apr 22, 2010 at 05:24:48PM -0400, m.roth at 5-cent.us wrote:
> >> Dominick wrote:
> >>> On Thu, Apr 22, 2010 at 04:25:58PM -0400, m.roth at 5-cent.us 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.

In my view it is CA that is failing. 

To quote Drepper on Execstack:

"As the name suggests, this error is raised if a program tries to make its stack (or parts thereof) executable with an mprotect call. This should never, ever be necessary. Stack memory is not executable on most OSes these days and this won't change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code."

Audit2allow cannot make security decisions for you and its advice may in fact be your best option. Note that i said:

"But writing policy is not a trivial task. I would be willing to help write policy if that is at all possible." 

A domain transition may or may not be possible. If it is not possible you will have to settle with audit2allows" suggestions.

> 
> 	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 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/20100423/b6ea474e/attachment.bin