Auditallow execmem

Auditallow execmem

[Daniel J Walsh]

Currently there are too many applications that need execmem, to turn off 
allow_execmem by default.  So I changed the policy
to auditallow execmem if there allow_execmem is set.  This allows us to 
at least discover applications in targeted policy that need
this priv, and then submit bugzillas for those apps, or fix policy to 
allow them if it really is needed.   The problem is that these messages 
are not rate limited so you can end up with hundreds or thousands of 
these messages in the log file.  What do you think about limiting 
auditallow message to once similar to the way we do in permissive mode?  
Since this is by it's nature permissive.  IE One pessage per PID.


type=AVC msg=audit(1136817016.558:1419): avc:  granted  { execmem } for  
pid=2774 comm="firefox-bin" scontext=user_u:system_r:unconfined_t:s0 
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
type=AVC msg=audit(1136817512.277:1420): avc:  granted  { execmem } for  
pid=3208 comm="soffice.bin" scontext=user_u:system_r:unconfined_t:s0 
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
type=AVC msg=audit(1136818328.051:1421): avc:  granted  { execmem } for  
pid=3208 comm="soffice.bin" scontext=user_u:system_r:unconfined_t:s0 
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
type=AVC msg=audit(1136819443.464:1428): avc:  granted  { execmem } for  
pid=3208 comm="soffice.bin" scontext=user_u:system_r:unconfined_t:s0 
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
type=AVC msg=audit(1136820377.510:1429): avc:  granted  { execmem } for  
pid=3208 comm="soffice.bin" scontext=user_u:system_r:unconfined_t:s0 
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
type=AVC msg=audit(1136821309.091:1435): avc:  granted  { execmem } for  
pid=3208 comm="soffice.bin" scontext=user_u:system_r:unconfined_t:s0 
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
type=AVC msg=audit(1136822165.482:1438): avc:  granted  { execmem } for  
pid=3208 comm="soffice.bin" scontext=user_u:system_r:unconfined_t:s0 
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
...

Dan

--
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: Auditallow execmem

[Stephen Smalley]

On Mon, 2006-01-09 at 11:09 -0500, Daniel J Walsh wrote:
> 
> Currently there are too many applications that need execmem, to turn off 
> allow_execmem by default.  So I changed the policy
> to auditallow execmem if there allow_execmem is set.  This allows us to 
> at least discover applications in targeted policy that need
> this priv, and then submit bugzillas for those apps, or fix policy to 
> allow them if it really is needed.   The problem is that these messages 
> are not rate limited so you can end up with hundreds or thousands of 
> these messages in the log file.  What do you think about limiting 
> auditallow message to once similar to the way we do in permissive mode?  
> Since this is by it's nature permissive.  IE One pessage per PID.

That would prevent use of 'auditallow' to audit every occurrence of a
security-sensitive event, which was its intended purpose.  Some uses of
auditallow (e.g. for logging all policy loads, setenforce operations,
etc) will be obsoleted by Steve G's patches adding explicit auditing of
such events outside of the AVC audit mechanism, but I'm hesitant to turn
auditallow entirely into a debugging-only tool in this manner.

Permissive mode avoids floods of denied messages on the same (source
context, target context, target class, permission) tuple by adding the
permission to the cache entry on the first denial, so subsequent checks
on the same tuple pass (until the cache entry is evicted by normal cache
activity or policy reload or switching to enforcing mode).

To do what you want and still support operational use of auditallow, I
think we'd need a way to mark specific auditallow rules as use-once,
with corresponding changes to the policy language, checkpolicy/libsepol,
and the kernel.  Not trivial, and it would take time to upstream.

Not sure whether it might be simpler to instead implement a solution in
the kernel audit framework for such selective filtering or in auditd
itself.

-- 
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: Auditallow execmem

[Joshua Brindle]

Stephen Smalley wrote:
> On Mon, 2006-01-09 at 11:09 -0500, Daniel J Walsh wrote:
> 
>>Currently there are too many applications that need execmem, to turn off 
>>allow_execmem by default.  So I changed the policy
>>to auditallow execmem if there allow_execmem is set.  This allows us to 
>>at least discover applications in targeted policy that need
>>this priv, and then submit bugzillas for those apps, or fix policy to 
>>allow them if it really is needed.   The problem is that these messages 
>>are not rate limited so you can end up with hundreds or thousands of 
>>these messages in the log file.  What do you think about limiting 
>>auditallow message to once similar to the way we do in permissive mode?  
>>Since this is by it's nature permissive.  IE One pessage per PID.
> 
> 
> That would prevent use of 'auditallow' to audit every occurrence of a
> security-sensitive event, which was its intended purpose.  Some uses of
> auditallow (e.g. for logging all policy loads, setenforce operations,
> etc) will be obsoleted by Steve G's patches adding explicit auditing of
> such events outside of the AVC audit mechanism, but I'm hesitant to turn
> auditallow entirely into a debugging-only tool in this manner.
> 
> Permissive mode avoids floods of denied messages on the same (source
> context, target context, target class, permission) tuple by adding the
> permission to the cache entry on the first denial, so subsequent checks
> on the same tuple pass (until the cache entry is evicted by normal cache
> activity or policy reload or switching to enforcing mode).
> 
> To do what you want and still support operational use of auditallow, I
> think we'd need a way to mark specific auditallow rules as use-once,
> with corresponding changes to the policy language, checkpolicy/libsepol,
> and the kernel.  Not trivial, and it would take time to upstream.
> 
> Not sure whether it might be simpler to instead implement a solution in
> the kernel audit framework for such selective filtering or in auditd
> itself.
> 

why not put an auditallow for execmem in a conditional so that you can 
instruct users to turn it on to get logs for the bug? That way 
additional language/kernel features wouldn't be required.

--
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: Auditallow execmem

[Steve G]

>Not sure whether it might be simpler to instead implement a solution in
>the kernel audit framework for such selective filtering or in auditd
>itself.

Not sure this is a good way to go at this point. The audit system is time
constrained. It is in a race with the kernel to keep the audit log queue as empty
as possible. The messages would be in text at this point which would require
parsing. I'd also have to keep a cache around and currently there's no malloc's
in the normal logging path to make sure we do not leak memory. (The audit daemon
makes itself exempt from OOM killer actions, so we try to make absolute sure this
could never happen.)

As for doing this in the audit framework, we have the same problem. SE Linux
currently calls audit_log_format which means we have everything in text by the
time we'd notice that its a duplicate. Parsing in the kernel doesn't sound good
to me. 

I don't think the audit subsystem should get in the business of message
compression either. This is one of the things that distinguish it from syslog.
You get all the messages all the time.

-Steve


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 


--
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.