Hi All,
So here is my problem statement:
While running in "Permissive" Mode, and keeping the
/selinux/avc/cache_threshold at the default 512 value, is there any
*other* way to make sure that EVERY SELinux violation attempt still
automatically gets logged into the audit.log file ???
Currently, while running in "Permissive" mode, and with the default
cache_threshold value of 512:
- if a violation is attempted, I see a deny event only once in the
audit.log file ! Successive violation attempts within the same session
are NOT logged in the audit.log file :( I need to get a DENY for every
violation attempt during runtime !
- When I run in "Enforcing" mode, every single violation does get logged
in the audit.log file. But at this time, lets just say I CANT afford to
run in Enforcing mode ! I must run in Permissive mode for now !
- If I change the cache_threshold to 0, every single violation attempt
does get logged, but I also get some other useless frequent periodic
violations. Besides, it seems to have performance impacts of course...
Therefore, I am looking for any other good way to generate a deny in the
audit.log for every violation attempt. But I cant change to Enforcing,
and I would prefer not to modify the cache_threshold.
Please help. Thanks,
-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
Sent: Thursday, October 18, 2007 8:14 AM
To: Hasan Rezaul-CHR010
Cc: Eric Paris; Daniel J Walsh; selinux@tycho.nsa.gov
Subject: RE: Recurring SELinux events for similar violations...
On Wed, 2007-10-17 at 18:22 -0400, Hasan Rezaul-CHR010 wrote:
> Yes, I am running in "Permissive" mode right now, just for testing
> purposes.
>
> If this is by design, is there any way I can force SELinux to log
every
> denial even in Permissive mode ?
It is by design, as otherwise you could end up with an unending stream
of duplicate denials since the application will keep on processing
(since the denials are not enforced), and thus flood the audit system
and logs with redundant information.
However, the denial will re-appear if the AVC entry is evicted. You can
manually flush the AVC by:
- toggling enforcing mode (e.g. setenforce 1; setenforce 0),
- setting a boolean (e.g. setsebool <somebool>=<somevalue>),
- reloading policy (e.g. /usr/sbin/load_policy)
Or you should be able to effectively turn off caching by setting the
cache threshold down (performance will naturally suffer as a result):
echo 0 > /selinux/avc/cache_threshold
cat /selinux/avc/cache_threshold
> Thanks,
>
> - Rezaul.
>
>
> -----Original Message-----
> From: Eric Paris [mailto:eparis@parisplace.org]
> Sent: Wednesday, October 17, 2007 5:19 PM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
> Subject: Re: Recurring SELinux events for similar violations...
>
> Are you running without enforcing just for testing? When you turn off
> enforcing it only logs once (by design) but I think it should log the
> denial every single time in enforcing mode.
>
> -Eric
>
> On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> > Hi All,
> >
> > I am using a Fedora 6 STRICT policy as my base, and have written
some
> > additional custom policies on top.
> >
> > For example, I have allowed certain domains (e.g. staff_t) to modify
> > file types of etc_t
> > And I have disallowed other domains (e.g. user_t) to modify file
types
> > of etc_t.
> >
> > When user_t makes the first attempt to modify an etc_t file, I do
get
> > DENY events :-)
> >
> > But subsequent attempts by user_t to modify etc_t files *DO NOT*
> > generate any more events ?!?
> >
> > - Is this by design ???
> >
> > - Is there something I can do such that EVERY time user_t attempts
> to
> > modify a file type etc_t , I will get a corresponding DENY ?
> >
> > - In other words, I would like every violation attempt to be
reported
> in
> > the audit.log file, even if the same violation occurs multiple times
> in
> > the same session.
> >
> > Thanks in advance,
> >
> > - Rezaul.
> >
> >
> > --
> > 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.
> >
>
>
> --
> 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.
--
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.
On Thu, 2007-11-29 at 15:06 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
>
> So here is my problem statement:
>
> While running in "Permissive" Mode, and keeping the
> /selinux/avc/cache_threshold at the default 512 value, is there any
> *other* way to make sure that EVERY SELinux violation attempt still
> automatically gets logged into the audit.log file ???
Not without patching your kernel, no. I already explained your options
here.
> Currently, while running in "Permissive" mode, and with the default
> cache_threshold value of 512:
>
> - if a violation is attempted, I see a deny event only once in the
> audit.log file ! Successive violation attempts within the same session
> are NOT logged in the audit.log file :( I need to get a DENY for every
> violation attempt during runtime !
Why? You are already getting one instance of each distinct denial, i.e.
each denial on a different (scontext, tcontext, tclass, permissions)
quadruple will appear exactly once, which is all you need in order to
create allow rules. Repeating those messages won't yield any more allow
rules, and it does have a cost - it commonly leads to audit flooding and
making the system unusable.
> - When I run in "Enforcing" mode, every single violation does get logged
> in the audit.log file. But at this time, lets just say I CANT afford to
> run in Enforcing mode ! I must run in Permissive mode for now !
Ok, fine.
> - If I change the cache_threshold to 0, every single violation attempt
> does get logged, but I also get some other useless frequent periodic
> violations. Besides, it seems to have performance impacts of course...
I don't understand. This gives you the behavior you want, but what are
these "useless frequent periodic violations" and why don't you want them
- you just said you wanted every denial. And yes, there will be a
performance impact, but if you are doing policy development, that
shouldn't matter, and performance testing should always happen _after_
constructing a working policy and moving into enforcing mode.
> Therefore, I am looking for any other good way to generate a deny in the
> audit.log for every violation attempt. But I cant change to Enforcing,
> and I would prefer not to modify the cache_threshold.
>
> Please help. Thanks,
>
> - Rezaul.
>
>
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Thursday, October 18, 2007 8:14 AM
> To: Hasan Rezaul-CHR010
> Cc: Eric Paris; Daniel J Walsh; selinux@tycho.nsa.gov
> Subject: RE: Recurring SELinux events for similar violations...
>
> On Wed, 2007-10-17 at 18:22 -0400, Hasan Rezaul-CHR010 wrote:
> > Yes, I am running in "Permissive" mode right now, just for testing
> > purposes.
> >
> > If this is by design, is there any way I can force SELinux to log
> every
> > denial even in Permissive mode ?
>
> It is by design, as otherwise you could end up with an unending stream
> of duplicate denials since the application will keep on processing
> (since the denials are not enforced), and thus flood the audit system
> and logs with redundant information.
>
> However, the denial will re-appear if the AVC entry is evicted. You can
> manually flush the AVC by:
> - toggling enforcing mode (e.g. setenforce 1; setenforce 0),
> - setting a boolean (e.g. setsebool <somebool>=<somevalue>),
> - reloading policy (e.g. /usr/sbin/load_policy)
>
> Or you should be able to effectively turn off caching by setting the
> cache threshold down (performance will naturally suffer as a result):
> echo 0 > /selinux/avc/cache_threshold
> cat /selinux/avc/cache_threshold
>
>
> > Thanks,
> >
> > - Rezaul.
> >
> >
> > -----Original Message-----
> > From: Eric Paris [mailto:eparis@parisplace.org]
> > Sent: Wednesday, October 17, 2007 5:19 PM
> > To: Hasan Rezaul-CHR010
> > Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
> > Subject: Re: Recurring SELinux events for similar violations...
> >
> > Are you running without enforcing just for testing? When you turn off
> > enforcing it only logs once (by design) but I think it should log the
> > denial every single time in enforcing mode.
> >
> > -Eric
> >
> > On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> > > Hi All,
> > >
> > > I am using a Fedora 6 STRICT policy as my base, and have written
> some
> > > additional custom policies on top.
> > >
> > > For example, I have allowed certain domains (e.g. staff_t) to modify
> > > file types of etc_t
> > > And I have disallowed other domains (e.g. user_t) to modify file
> types
> > > of etc_t.
> > >
> > > When user_t makes the first attempt to modify an etc_t file, I do
> get
> > > DENY events :-)
> > >
> > > But subsequent attempts by user_t to modify etc_t files *DO NOT*
> > > generate any more events ?!?
> > >
> > > - Is this by design ???
> > >
> > > - Is there something I can do such that EVERY time user_t attempts
> > to
> > > modify a file type etc_t , I will get a corresponding DENY ?
> > >
> > > - In other words, I would like every violation attempt to be
> reported
> > in
> > > the audit.log file, even if the same violation occurs multiple times
> > in
> > > the same session.
> > >
> > > Thanks in advance,
> > >
> > > - Rezaul.
> > >
> > >
> > > --
> > > 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.
> > >
> >
> >
> > --
> > 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.
--
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.
Hi Stephen,
Thanks as always for your response :-)
I have already created a set of allow rules necessary. So we're using
SELinux is to capture info about EVERY attempt an unauthorized/rogue
user makes to access something they're NOT supposed to! So the reason I
want to see the DENY events in audit.log, is *NOT* for creating
corresponding allow rules.
The "frequent periodic violation" I was referring to is as follows:
type=AVC msg=audit(1196369398.427:126): avc: denied { read } for
pid=1040 com
m="klogd" name="kmsg" dev=proc ino=-268435446
scontext=system_u:system_r:kernel_
t:s0 tcontext=system_u:object_r:proc_kmsg_t:s0 tclass=file
With [ /avc/cache_threshold = 0 ], the above event keeps popping up in
audit.log every second ! I would like to create an allow rule, to get
rid of this event. When I used audit2allow to generate the allow rule, I
got:
allow kernel_t proc_kmsg_t:file read
However, the base policy I am using as my starting policy is the
*STRICT* Fedora Core 6 policy. And with that in place, when I try to
insert this allow rule using (semodule -i myPolicy.pp), I get an
assertion failure for that allow rule!!! So seems like the base policy
wont let me insert this allow rule :-(
So that is my dilemma.
With cache_threshold = 0, I get all the denies I want to see. But I
also get these extra denies that I cant get rid off :-(
-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
On Behalf Of Stephen Smalley
Sent: Thursday, November 29, 2007 2:17 PM
To: Hasan Rezaul-CHR010
Cc: Daniel J Walsh; selinux@tycho.nsa.gov
Subject: RE: Recurring SELinux events for similar violations...
On Thu, 2007-11-29 at 15:06 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
>
> So here is my problem statement:
>
> While running in "Permissive" Mode, and keeping the
> /selinux/avc/cache_threshold at the default 512 value, is there any
> *other* way to make sure that EVERY SELinux violation attempt still
> automatically gets logged into the audit.log file ???
Not without patching your kernel, no. I already explained your options
here.
> Currently, while running in "Permissive" mode, and with the default
> cache_threshold value of 512:
>
> - if a violation is attempted, I see a deny event only once in the
> audit.log file ! Successive violation attempts within the same session
> are NOT logged in the audit.log file :( I need to get a DENY for
every
> violation attempt during runtime !
Why? You are already getting one instance of each distinct denial, i.e.
each denial on a different (scontext, tcontext, tclass, permissions)
quadruple will appear exactly once, which is all you need in order to
create allow rules. Repeating those messages won't yield any more allow
rules, and it does have a cost - it commonly leads to audit flooding and
making the system unusable.
> - When I run in "Enforcing" mode, every single violation does get
logged
> in the audit.log file. But at this time, lets just say I CANT afford
to
> run in Enforcing mode ! I must run in Permissive mode for now !
Ok, fine.
> - If I change the cache_threshold to 0, every single violation attempt
> does get logged, but I also get some other useless frequent periodic
> violations. Besides, it seems to have performance impacts of course...
I don't understand. This gives you the behavior you want, but what are
these "useless frequent periodic violations" and why don't you want them
- you just said you wanted every denial. And yes, there will be a
performance impact, but if you are doing policy development, that
shouldn't matter, and performance testing should always happen _after_
constructing a working policy and moving into enforcing mode.
> Therefore, I am looking for any other good way to generate a deny in
the
> audit.log for every violation attempt. But I cant change to Enforcing,
> and I would prefer not to modify the cache_threshold.
>
> Please help. Thanks,
>
> - Rezaul.
>
>
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Thursday, October 18, 2007 8:14 AM
> To: Hasan Rezaul-CHR010
> Cc: Eric Paris; Daniel J Walsh; selinux@tycho.nsa.gov
> Subject: RE: Recurring SELinux events for similar violations...
>
> On Wed, 2007-10-17 at 18:22 -0400, Hasan Rezaul-CHR010 wrote:
> > Yes, I am running in "Permissive" mode right now, just for testing
> > purposes.
> >
> > If this is by design, is there any way I can force SELinux to log
> every
> > denial even in Permissive mode ?
>
> It is by design, as otherwise you could end up with an unending stream
> of duplicate denials since the application will keep on processing
> (since the denials are not enforced), and thus flood the audit system
> and logs with redundant information.
>
> However, the denial will re-appear if the AVC entry is evicted. You
can
> manually flush the AVC by:
> - toggling enforcing mode (e.g. setenforce 1; setenforce 0),
> - setting a boolean (e.g. setsebool <somebool>=<somevalue>),
> - reloading policy (e.g. /usr/sbin/load_policy)
>
> Or you should be able to effectively turn off caching by setting the
> cache threshold down (performance will naturally suffer as a result):
> echo 0 > /selinux/avc/cache_threshold
> cat /selinux/avc/cache_threshold
>
>
> > Thanks,
> >
> > - Rezaul.
> >
> >
> > -----Original Message-----
> > From: Eric Paris [mailto:eparis@parisplace.org]
> > Sent: Wednesday, October 17, 2007 5:19 PM
> > To: Hasan Rezaul-CHR010
> > Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
> > Subject: Re: Recurring SELinux events for similar violations...
> >
> > Are you running without enforcing just for testing? When you turn
off
> > enforcing it only logs once (by design) but I think it should log
the
> > denial every single time in enforcing mode.
> >
> > -Eric
> >
> > On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> > > Hi All,
> > >
> > > I am using a Fedora 6 STRICT policy as my base, and have written
> some
> > > additional custom policies on top.
> > >
> > > For example, I have allowed certain domains (e.g. staff_t) to
modify
> > > file types of etc_t
> > > And I have disallowed other domains (e.g. user_t) to modify file
> types
> > > of etc_t.
> > >
> > > When user_t makes the first attempt to modify an etc_t file, I do
> get
> > > DENY events :-)
> > >
> > > But subsequent attempts by user_t to modify etc_t files *DO NOT*
> > > generate any more events ?!?
> > >
> > > - Is this by design ???
> > >
> > > - Is there something I can do such that EVERY time user_t
attempts
> > to
> > > modify a file type etc_t , I will get a corresponding DENY ?
> > >
> > > - In other words, I would like every violation attempt to be
> reported
> > in
> > > the audit.log file, even if the same violation occurs multiple
times
> > in
> > > the same session.
> > >
> > > Thanks in advance,
> > >
> > > - Rezaul.
> > >
> > >
> > > --
> > > 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.
> > >
> >
> >
> > --
> > 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.
--
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.
--
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.
On Thu, 2007-11-29 at 16:26 -0500, Hasan Rezaul-CHR010 wrote:
> Hi Stephen,
>
> Thanks as always for your response :-)
>
> I have already created a set of allow rules necessary. So we're using
> SELinux is to capture info about EVERY attempt an unauthorized/rogue
> user makes to access something they're NOT supposed to! So the reason I
> want to see the DENY events in audit.log, is *NOT* for creating
> corresponding allow rules.
>
> The "frequent periodic violation" I was referring to is as follows:
>
> type=AVC msg=audit(1196369398.427:126): avc: denied { read } for
> pid=1040 com
> m="klogd" name="kmsg" dev=proc ino=-268435446
> scontext=system_u:system_r:kernel_
> t:s0 tcontext=system_u:object_r:proc_kmsg_t:s0 tclass=file
So you never transitioned out of kernel_t (initial kernel task and
kernel threads) into appropriate domains for userland (starting with a
transition to init_t upon /sbin/init, init_exec_t). Normally klogd
would run in klogd_t, and the above would be allowed by policy.
> With [ /avc/cache_threshold = 0 ], the above event keeps popping up in
> audit.log every second ! I would like to create an allow rule, to get
> rid of this event. When I used audit2allow to generate the allow rule, I
> got:
>
> allow kernel_t proc_kmsg_t:file read
>
>
> However, the base policy I am using as my starting policy is the
> *STRICT* Fedora Core 6 policy. And with that in place, when I try to
> insert this allow rule using (semodule -i myPolicy.pp), I get an
> assertion failure for that allow rule!!! So seems like the base policy
> wont let me insert this allow rule :-(
Which is good, because it indicates a more fundamental problem - you've
got a mislabeled klogd process.
But suppose that wasn't the case and you truly wanted to allow that.
Here is how you would do it:
1) Look for a refpolicy interface that grants access to kmsg. In a
modern policy, that appears to be kernel_read_messages(). Then write
your policy module using that interface, ala:
$ vi myklogd.te
policy_module(myklogd, 1.0)
require {
type kernel_t;
}
kernel_read_messages(kernel_t)
:wq
$ make -f /usr/share/selinux/devel/Makefile
$ su
# /usr/sbin/semodule -i myklogd.pp
The refpolicy interface contains the 'magic' needed to override this
assertion, namely adding an attribute to the kernel_t type. This
ensures that you made a conscious decision to give access to this
security-relevant resource and didn't accidentally do it via
audit2allow.
-or-
2) Disable assertion checking by libsemanage (not recommended, mostly
for developers, but if you need it, it exists):
$ su
# vi /etc/selinux/semanage.conf
:$
i
expand-check=0
:wq
> So that is my dilemma.
> With cache_threshold = 0, I get all the denies I want to see. But I
> also get these extra denies that I cant get rid off :-(
--
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.
On Thu, 2007-11-29 at 16:32 -0500, Stephen Smalley wrote:
> On Thu, 2007-11-29 at 16:26 -0500, Hasan Rezaul-CHR010 wrote:
> > Hi Stephen,
> >
> > Thanks as always for your response :-)
> >
> > I have already created a set of allow rules necessary. So we're using
> > SELinux is to capture info about EVERY attempt an unauthorized/rogue
> > user makes to access something they're NOT supposed to! So the reason I
> > want to see the DENY events in audit.log, is *NOT* for creating
> > corresponding allow rules.
> >
> > The "frequent periodic violation" I was referring to is as follows:
> >
> > type=AVC msg=audit(1196369398.427:126): avc: denied { read } for
> > pid=1040 com
> > m="klogd" name="kmsg" dev=proc ino=-268435446
> > scontext=system_u:system_r:kernel_
> > t:s0 tcontext=system_u:object_r:proc_kmsg_t:s0 tclass=file
>
> So you never transitioned out of kernel_t (initial kernel task and
> kernel threads) into appropriate domains for userland (starting with a
> transition to init_t upon /sbin/init, init_exec_t). Normally klogd
> would run in klogd_t, and the above would be allowed by policy.
>
> > With [ /avc/cache_threshold = 0 ], the above event keeps popping up in
> > audit.log every second ! I would like to create an allow rule, to get
> > rid of this event. When I used audit2allow to generate the allow rule, I
> > got:
> >
> > allow kernel_t proc_kmsg_t:file read
> >
> >
> > However, the base policy I am using as my starting policy is the
> > *STRICT* Fedora Core 6 policy. And with that in place, when I try to
> > insert this allow rule using (semodule -i myPolicy.pp), I get an
> > assertion failure for that allow rule!!! So seems like the base policy
> > wont let me insert this allow rule :-(
>
> Which is good, because it indicates a more fundamental problem - you've
> got a mislabeled klogd process.
>
> But suppose that wasn't the case and you truly wanted to allow that.
> Here is how you would do it:
> 1) Look for a refpolicy interface that grants access to kmsg. In a
> modern policy, that appears to be kernel_read_messages(). Then write
> your policy module using that interface, ala:
> $ vi myklogd.te
> policy_module(myklogd, 1.0)
> require {
> type kernel_t;
> }
> kernel_read_messages(kernel_t)
> :wq
> $ make -f /usr/share/selinux/devel/Makefile
> $ su
> # /usr/sbin/semodule -i myklogd.pp
>
> The refpolicy interface contains the 'magic' needed to override this
> assertion, namely adding an attribute to the kernel_t type. This
> ensures that you made a conscious decision to give access to this
> security-relevant resource and didn't accidentally do it via
> audit2allow.
>
> -or-
> 2) Disable assertion checking by libsemanage (not recommended, mostly
> for developers, but if you need it, it exists):
> $ su
> # vi /etc/selinux/semanage.conf
> :$
> i
> expand-check=0
> :wq
>
> > So that is my dilemma.
> > With cache_threshold = 0, I get all the denies I want to see. But I
> > also get these extra denies that I cant get rid off :-(
Also, it would be very simple to patch your kernel to not have this
behavior in permissive mode if you truly wanted that. Just look in
linux-2.6/security/selinux/avc.c in the avc_has_perm_noaudit() function,
and remove where it calls avc_update_node(AVC_CALLBACK_GRANT...). Then
it won't add those permissions to the cached entry, and it will keep
auditing them every time. I suppose we could make that
configurable/tunable in future kernels if there is a real demand for it.
--
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.