All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Justin P. Mattock" <justinmattock@gmail.com>
To: Guido Trentalancia <guido@trentalancia.com>
Cc: SE-Linux <selinux@tycho.nsa.gov>, xorg <xorg@freedesktop.org>,
	refpolicy@oss1.tresys.com
Subject: Re: avc's generated causes the system to freeze up
Date: Mon, 14 Dec 2009 09:15:18 -0800	[thread overview]
Message-ID: <4B2672A6.50906@gmail.com> (raw)
In-Reply-To: <1260807309.2853.55.camel@tesla.lan>

On 12/14/09 08:15, Guido Trentalancia wrote:
> Auditctl should operate at kernel-level. But this topics are all
> off-theme from SELinux. You shouldn't post audit questions to a SELinux
> mailing list.
>
>


Probably should be refpolicy, and Xorg
because this pertains to
XACE, but you took these cc's off the e-mail!

Anyways, as for auditd keep in mind this has todo with
Xorg.0.log, nothing todo with anything
in /var/log/messages, or any other log message
that auditd reads(and remember I don't have auditd turned on).

So lets try again:

I'm running X.Org X Server 1.7.99.2
after building the latest refpolicy
and defining my allow rules(all of them as possible),
I seem to have some of them show up later in time.
(which is normal).

The problem that I have is on some occasions these
denials that show up long after I have defined as many
allow rules as possible, seem to be spamming my
Xorg.0.log, until I define them into the policy
with audit2allow.

my question is, is there a mechanism similar to printk_ratelimit
for Xorg.0.log so when this happens my Xorg.0.log
does not become spammed with one avc denial
causing my system to freeze up, until the avc denial has
done registering all of it's denials or I allow it into the policy?


Justin P. mattock

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

WARNING: multiple messages have this Message-ID (diff)
From: justinmattock@gmail.com (Justin P. Mattock)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] avc's generated causes the system to freeze up
Date: Mon, 14 Dec 2009 09:15:18 -0800	[thread overview]
Message-ID: <4B2672A6.50906@gmail.com> (raw)
In-Reply-To: <1260807309.2853.55.camel@tesla.lan>

On 12/14/09 08:15, Guido Trentalancia wrote:
> Auditctl should operate at kernel-level. But this topics are all
> off-theme from SELinux. You shouldn't post audit questions to a SELinux
> mailing list.
>
>


Probably should be refpolicy, and Xorg
because this pertains to
XACE, but you took these cc's off the e-mail!

Anyways, as for auditd keep in mind this has todo with
Xorg.0.log, nothing todo with anything
in /var/log/messages, or any other log message
that auditd reads(and remember I don't have auditd turned on).

So lets try again:

I'm running X.Org X Server 1.7.99.2
after building the latest refpolicy
and defining my allow rules(all of them as possible),
I seem to have some of them show up later in time.
(which is normal).

The problem that I have is on some occasions these
denials that show up long after I have defined as many
allow rules as possible, seem to be spamming my
Xorg.0.log, until I define them into the policy
with audit2allow.

my question is, is there a mechanism similar to printk_ratelimit
for Xorg.0.log so when this happens my Xorg.0.log
does not become spammed with one avc denial
causing my system to freeze up, until the avc denial has
done registering all of it's denials or I allow it into the policy?


Justin P. mattock

  reply	other threads:[~2009-12-14 17:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-11 21:44 avc's generated causes the system to freeze up Justin Mattock
2009-12-11 21:44 ` [refpolicy] " Justin Mattock
2009-12-13 16:42 ` Guido Trentalancia
2009-12-13 18:11   ` Justin P. Mattock
2009-12-13 19:40     ` Guido Trentalancia
2009-12-13 20:23       ` Justin P. Mattock
2009-12-14  9:56         ` Guido Trentalancia
2009-12-14 16:11           ` Justin P. Mattock
2009-12-14 16:15             ` Guido Trentalancia
2009-12-14 17:15               ` Justin P. Mattock [this message]
2009-12-14 17:15                 ` [refpolicy] " Justin P. Mattock
2009-12-14 17:37 ` Eamon Walsh
2009-12-14 17:37   ` [refpolicy] " Eamon Walsh
2009-12-14 18:39   ` Justin P. Mattock
2009-12-14 18:39     ` [refpolicy] " Justin P. Mattock
2009-12-14 18:39   ` Xavier Toth
2009-12-14 18:39     ` [refpolicy] " Xavier Toth
2009-12-14 19:13     ` Justin P. Mattock
2009-12-14 19:13       ` [refpolicy] " Justin P. Mattock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B2672A6.50906@gmail.com \
    --to=justinmattock@gmail.com \
    --cc=guido@trentalancia.com \
    --cc=refpolicy@oss1.tresys.com \
    --cc=selinux@tycho.nsa.gov \
    --cc=xorg@freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.