tracking down execstack & execmem violations

tracking down execstack & execmem violations

[Clarkson, Mike R (US SSA)]

I'm writing a policy for a very large legacy CORBA application, with
many separate processes. Without fail, every one of our processes
requires execstack & execmem privileges. I would like to track down the
cause, but I really don't have any idea how. Does anybody have any good
recommendations?

I'd like to at least be able to determine whether the offending code is
ours or some vender's (like our CORBA vender), and if it is ours I'd
like to track down the source. I'm betting there is a common source
causing the issue.

Thanks







--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: tracking down execstack & execmem violations

[Stephen Smalley]

On Tue, 2008-06-10 at 10:10 -0700, Clarkson, Mike R (US SSA) wrote:
> I'm writing a policy for a very large legacy CORBA application, with
> many separate processes. Without fail, every one of our processes
> requires execstack & execmem privileges. I would like to track down the
> cause, but I really don't have any idea how. Does anybody have any good
> recommendations?
> 
> I'd like to at least be able to determine whether the offending code is
> ours or some vender's (like our CORBA vender), and if it is ours I'd
> like to track down the source. I'm betting there is a common source
> causing the issue.

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

Also, what does execstack -q show for the executables in question?
And are these programs:
- multi-threaded?,
- Java-based?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: tracking down execstack & execmem violations

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Tuesday, June 10, 2008 10:15 AM
> To: Clarkson, Mike R (US SSA)
> Cc: selinux@tycho.nsa.gov
> Subject: Re: tracking down execstack & execmem violations
> 
> 
> On Tue, 2008-06-10 at 10:10 -0700, Clarkson, Mike R (US SSA) wrote:
> > I'm writing a policy for a very large legacy CORBA application, with
> > many separate processes. Without fail, every one of our processes
> > requires execstack & execmem privileges. I would like to track down
the
> > cause, but I really don't have any idea how. Does anybody have any
good
> > recommendations?
> >
> > I'd like to at least be able to determine whether the offending code
is
> > ours or some vender's (like our CORBA vender), and if it is ours I'd
> > like to track down the source. I'm betting there is a common source
> > causing the issue.
> 
> Resources:
> http://people.redhat.com/drepper/selinux-mem.html
> http://people.redhat.com/drepper/nonselsec.pdf

I'll look at these. Thanks!
> 
> Also, what does execstack -q show for the executables in question?

I wasn't aware of the execstack cmd. This alone will help a lot. Thanks
again.

> And are these programs:
> - multi-threaded?,
> - Java-based?

Mostly C++ but a few Java. Nearly all are multi-threaded.

> 
> --
> Stephen Smalley
> National Security Agency




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: tracking down execstack & execmem violations

[Stephen Smalley]

On Tue, 2008-06-10 at 10:23 -0700, Clarkson, Mike R (US SSA) wrote:
> 
> > -----Original Message-----
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> > Sent: Tuesday, June 10, 2008 10:15 AM
> > To: Clarkson, Mike R (US SSA)
> > Cc: selinux@tycho.nsa.gov
> > Subject: Re: tracking down execstack & execmem violations
> > 
> > 
> > On Tue, 2008-06-10 at 10:10 -0700, Clarkson, Mike R (US SSA) wrote:
> > > I'm writing a policy for a very large legacy CORBA application, with
> > > many separate processes. Without fail, every one of our processes
> > > requires execstack & execmem privileges. I would like to track down
> the
> > > cause, but I really don't have any idea how. Does anybody have any
> good
> > > recommendations?
> > >
> > > I'd like to at least be able to determine whether the offending code
> is
> > > ours or some vender's (like our CORBA vender), and if it is ours I'd
> > > like to track down the source. I'm betting there is a common source
> > > causing the issue.
> > 
> > Resources:
> > http://people.redhat.com/drepper/selinux-mem.html
> > http://people.redhat.com/drepper/nonselsec.pdf
> 
> I'll look at these. Thanks!
> > 
> > Also, what does execstack -q show for the executables in question?
> 
> I wasn't aware of the execstack cmd. This alone will help a lot. Thanks
> again.
> 
> > And are these programs:
> > - multi-threaded?,
> > - Java-based?
> 
> Mostly C++ but a few Java. Nearly all are multi-threaded.

Java is known to require execmem for runtime code generation.  There is
a java_t domain that you can look at as an example.  I think they allow
it execstack too, although I'm not as clear as to why that is necessary,
possibly for the thread stack allocation.

Thread stacks may be allocated with PROT_EXEC if the executable is
marked as requiring an executable stack or if it lacks the marking;
execstack should tell you the story there.

If we can't give execmem w/o giving execstack too, then execstack isn't
useful as a separate permission.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: tracking down execstack & execmem violations

[Eric Paris]

On Tue, Jun 10, 2008 at 1:49 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> Java is known to require execmem for runtime code generation.  There is
> a java_t domain that you can look at as an example.  I think they allow
> it execstack too, although I'm not as clear as to why that is necessary,
> possibly for the thread stack allocation.
>
> Thread stacks may be allocated with PROT_EXEC if the executable is
> marked as requiring an executable stack or if it lacks the marking;
> execstack should tell you the story there.
>
> If we can't give execmem w/o giving execstack too, then execstack isn't
> useful as a separate permission.

As I recall, which is always a dangerous thing for me todo, execstack
needs execmem for multithreaded processes because the 'stack' of the
second thread is just 'memory' from the point of view of the
permission checks.

execmem does not need execstack.....

java probably actually uses an executable stack which is why it needs both.....

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: tracking down execstack & execmem violations

[Daniel J Walsh]

Eric Paris wrote:
> On Tue, Jun 10, 2008 at 1:49 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
>> Java is known to require execmem for runtime code generation.  There is
>> a java_t domain that you can look at as an example.  I think they allow
>> it execstack too, although I'm not as clear as to why that is necessary,
>> possibly for the thread stack allocation.
>>
>> Thread stacks may be allocated with PROT_EXEC if the executable is
>> marked as requiring an executable stack or if it lacks the marking;
>> execstack should tell you the story there.
>>
>> If we can't give execmem w/o giving execstack too, then execstack isn't
>> useful as a separate permission.
> 
> As I recall, which is always a dangerous thing for me todo, execstack
> needs execmem for multithreaded processes because the 'stack' of the
> second thread is just 'memory' from the point of view of the
> permission checks.
> 
> execmem does not need execstack.....
> 
> java probably actually uses an executable stack which is why it needs both.....
I believe it was only one of the java implementations that needed
execstack.  The others did not, but it was either to just allow it for all.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: tracking down execstack & execmem violations

[Stephen Smalley]

On Tue, 2008-06-10 at 14:00 -0400, Eric Paris wrote:
> On Tue, Jun 10, 2008 at 1:49 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > Java is known to require execmem for runtime code generation.  There is
> > a java_t domain that you can look at as an example.  I think they allow
> > it execstack too, although I'm not as clear as to why that is necessary,
> > possibly for the thread stack allocation.
> >
> > Thread stacks may be allocated with PROT_EXEC if the executable is
> > marked as requiring an executable stack or if it lacks the marking;
> > execstack should tell you the story there.
> >
> > If we can't give execmem w/o giving execstack too, then execstack isn't
> > useful as a separate permission.
> 
> As I recall, which is always a dangerous thing for me todo, execstack
> needs execmem for multithreaded processes because the 'stack' of the
> second thread is just 'memory' from the point of view of the
> permission checks.

Yes, that one I understand and am ok with.

> execmem does not need execstack.....

That is theoretically true but I wasn't sure we had real working
examples of programs that only require the former and not the latter.

> java probably actually uses an executable stack which is why it needs both.....
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.