selinux and udev ?

[Tom London]

There are reports in fedora-test about the 2.X policy slowing down
udev. (Appears that folks are comparing booting with selinxux=1 with
selinux=0).

I have to admit that udev is running slower (targeted/enforcing).

Any validity to this?  Known issue? How to track down?

tom
--
Tom London

[Stephen Smalley]

On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote:
> There are reports in fedora-test about the 2.X policy slowing down
> udev. (Appears that folks are comparing booting with selinxux=1 with
> selinux=0).
>
> I have to admit that udev is running slower (targeted/enforcing).
>
> Any validity to this?  Known issue? How to track down?

First, check whether you have any avc denials associated with udev in
your audit.log.

If not, then the slowdown is likely in matchpathcon(3), used to match a
path against the file_contexts configuration to obtain a security
context to apply to the device node.  Could be a result of:
- differences in the file_contexts configurations between reference
policy and the original targeted policy (ordering, regex stem lengths,
regex complexity, number of entries, ...),
- the introduction of context canonicalization into matchpathcon(3) to
avoid problems with type aliases (in which case it shouldn't be
different between reference policy and the original targeted policy,
just between old libselinux/kernel versus newer libselinux/kernel
combination - you need both a recent libselinux and a recent kernel to
have the canonicalization support enabled).

[Stephen Smalley]

On Tue, 2005-11-29 at 11:48 -0500, Stephen Smalley wrote:
> On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote:
> > There are reports in fedora-test about the 2.X policy slowing down
> > udev. (Appears that folks are comparing booting with selinxux=1 with
> > selinux=0).
> >
> > I have to admit that udev is running slower (targeted/enforcing).
> >
> > Any validity to this?  Known issue? How to track down?
>
> First, check whether you have any avc denials associated with udev in
> your audit.log.
>
> If not, then the slowdown is likely in matchpathcon(3), used to match a
> path against the file_contexts configuration to obtain a security
> context to apply to the device node.  Could be a result of:
> differences in the file_contexts configurations between reference
>
> policy and the original targeted policy (ordering, regex stem lengths,
> regex complexity, number of entries, ...),
> the introduction of context canonicalization into matchpathcon(3) to
>
> avoid problems with type aliases (in which case it shouldn't be
> different between reference policy and the original targeted policy,
> just between old libselinux/kernel versus newer libselinux/kernel
> combination - you need both a recent libselinux and a recent kernel to
> have the canonicalization support enabled).

Random thought:  As udev only manages devices, why not run file_contexts
through a filter to extract /dev entries at policy build time, saving
the result as a file_contexts.dev file, and have udev use
matchpathcon_init() to select that file for its matching.  That would
then avoid having to process the entire file contexts configuration for
udev.

[Stephen Smalley]

On Tue, 2005-11-29 at 11:51 -0500, Stephen Smalley wrote:
> Random thought:  As udev only manages devices, why not run file_contexts
> through a filter to extract /dev entries at policy build time, saving
> the result as a file_contexts.dev file, and have udev use
> matchpathcon_init() to select that file for its matching.  That would
> then avoid having to process the entire file contexts configuration for
> udev.

An unscientific experiment, with a slightly modified matchpathcon util
that lets me specify the file_contexts path:

$ grep '^/dev' file_contexts > file_contexts.dev
$ time ./matchpathcon -f file_contexts.dev /dev/ttyS0
/dev/ttyS0      system_u:object_r:tty_device_t

real    0m0.023s
user    0m0.012s
sys     0m0.008s
$ time ./matchpathcon -f file_contexts /dev/ttyS0
/dev/ttyS0      system_u:object_r:tty_device_t

real    0m0.216s
user    0m0.152s
sys     0m0.064s

Quite the difference, no?

[Tom London]

On 11/29/05, Stephen Smalley  wrote:
> On Tue, 2005-11-29 at 11:51 -0500, Stephen Smalley wrote:
> > Random thought:  As udev only manages devices, why not run file_contexts
> > through a filter to extract /dev entries at policy build time, saving
> > the result as a file_contexts.dev file, and have udev use
> > matchpathcon_init() to select that file for its matching.  That would
> > then avoid having to process the entire file contexts configuration for
> > udev.
>
> An unscientific experiment, with a slightly modified matchpathcon util
> that lets me specify the file_contexts path:
>
> $ grep '^/dev' file_contexts > file_contexts.dev
> $ time ./matchpathcon -f file_contexts.dev /dev/ttyS0
> /dev/ttyS0      system_u:object_r:tty_device_t
>
> real    0m0.023s
> user    0m0.012s
> sys     0m0.008s
> $ time ./matchpathcon -f file_contexts /dev/ttyS0
> /dev/ttyS0      system_u:object_r:tty_device_t
>
> real    0m0.216s
> user    0m0.152s
> sys     0m0.064s
>
> Quite the difference, no?

Cool. I take it matchpathcon() is called approx. once per created
entry in /dev, etc. If so, 'du -a /dev | wc' reports about 310 entries
on my system.

If so, that would be noticable. ;)
   tom

--
Tom London

[Ivan Gyurdiev]

> Quite the difference, no?

Maybe this could be generalized (what's special about /dev?).
"make install"  does not need to analyze all the paths on the system 
(per file!)...

[Tom London]

On 11/29/05, Ivan Gyurdiev  wrote:
> > Quite the difference, no?
>
> Maybe this could be generalized (what's special about /dev?).
> "make install"  does not need to analyze all the paths on the system
> (per file!)...

Hmm....

This sort of suggests a different file organization, no?

How about 'overlaying' something like a trie or some search tree
organized by directory 'prefixes' (e.g., '/dev', '/lib', etc.). Should
be possible to organize the general matching cases into one bucket.

tom
--
Tom London

[Stephen Smalley]

On Tue, 2005-11-29 at 09:43 -0800, Tom London wrote:
> On 11/29/05, Ivan Gyurdiev  wrote:
> > > Quite the difference, no?
> >
> > Maybe this could be generalized (what's special about /dev?).
> > "make install"  does not need to analyze all the paths on the system
> > (per file!)...
>
> Hmm....
>
> This sort of suggests a different file organization, no?
>
> How about 'overlaying' something like a trie or some search tree
> organized by directory 'prefixes' (e.g., '/dev', '/lib', etc.). Should
> be possible to organize the general matching cases into one bucket.

IIUC, the primary overhead isn't during the matching phase; it is during
initial processing of file_contexts by matchpathcon_init(), when it
loads the entire file_contexts configuration into the in-memory
representation and compiles all of the regexes.  Most of the time is
spent in regcomp().  So the only way to reduce it is to reduce the set
of entries processed during matchpathcon_init(), which doesn't know what
paths you are going to subsequently try matching via matchpathcon().

The expected usage model was that matchpathcon_init() would be invoked
once followed by multiple matchpathcon() calls by the application, as in
setfiles and restorecon (the original users).  IIUC, udev is executed on
each event, so it ends up performing matchpathcon_init() on every node
creation and we don't get any caching of the data.

We could introduce a variant interface that is optimized for the case
where you are only going to perform matchpathcon() calls on paths with a
common prefix (e.g. /dev), or the SELinux support in udev could be
re-visited (leveraging the udevd daemon to cache the data once for all
udev instances?).

[Stephen Smalley]

On Tue, 2005-11-29 at 13:22 -0500, Stephen Smalley wrote:
> We could introduce a variant interface that is optimized for the case
> where you are only going to perform matchpathcon() calls on paths with a
> common prefix (e.g. /dev), or the SELinux support in udev could be
> re-visited (leveraging the udevd daemon to cache the data once for all
> udev instances?).

Note that the latter might not help with system initialization, as I
assume udev is still executed separately each time during early
initialization prior to the start of udevd?

[Nicolas Mailhot]

Le mardi 29 novembre 2005 à 11:48 -0500, Stephen Smalley a écrit :
> On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote:
> > There are reports in fedora-test about the 2.X policy slowing down
> > udev. (Appears that folks are comparing booting with selinxux=1 with
> > selinux=0).
> >
> > I have to admit that udev is running slower (targeted/enforcing).
> >
> > Any validity to this?  Known issue? How to track down?
>
> First, check whether you have any avc denials associated with udev in
> your audit.log.

There are certainly many denials with the new 2.0 policy, including udev
stuff (at least it was the case a week ago). I've posted 2.0 audit logs
many times in bugzilla.

[Stephen Smalley]

On Tue, 2005-11-29 at 18:56 +0100, Nicolas Mailhot wrote:
> Le mardi 29 novembre 2005 à 11:48 -0500, Stephen Smalley a écrit :
> > On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote:
> > > There are reports in fedora-test about the 2.X policy slowing down
> > > udev. (Appears that folks are comparing booting with selinxux=1 with
> > > selinux=0).
> > >
> > > I have to admit that udev is running slower (targeted/enforcing).
> > >
> > > Any validity to this?  Known issue? How to track down?
> >
> > First, check whether you have any avc denials associated with udev in
> > your audit.log.
>
> There are certainly many denials with the new 2.0 policy, including udev
> stuff (at least it was the case a week ago). I've posted 2.0 audit logs
> many times in bugzilla.

I think many of those avc issues have been resolved, although there may
still be lingering ones.  I think that the udev slowdown is more likely
matchpathcon / file_contexts issues.

[Nicolas Mailhot]

Le mardi 29 novembre 2005 à 13:23 -0500, Stephen Smalley a écrit :
> On Tue, 2005-11-29 at 18:56 +0100, Nicolas Mailhot wrote:
> > Le mardi 29 novembre 2005 à 11:48 -0500, Stephen Smalley a écrit :
> > > On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote:
> > > > There are reports in fedora-test about the 2.X policy slowing down
> > > > udev. (Appears that folks are comparing booting with selinxux=1 with
> > > > selinux=0).
> > > >
> > > > I have to admit that udev is running slower (targeted/enforcing).
> > > >
> > > > Any validity to this?  Known issue? How to track down?
> > >
> > > First, check whether you have any avc denials associated with udev in
> > > your audit.log.
> >
> > There are certainly many denials with the new 2.0 policy, including udev
> > stuff (at least it was the case a week ago). I've posted 2.0 audit logs
> > many times in bugzilla.
>
> I think many of those avc issues have been resolved, although there may
> still be lingering ones.  I think that the udev slowdown is more likely
> matchpathcon / file_contexts issues.

The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So
things get (slowly) fixed. But most issues are still there :

audit2allow < /var/log/audit/audit.log
allow dovecot_auth_t var_lib_t:dir search;
allow system_chkpwd_t devpts_t:chr_file { read write };
allow procmail_t spamd_port_t:tcp_socket name_connect;
allow updfstab_t tmpfs_t:dir getattr;
allow dovecot_auth_t etc_runtime_t:file read;
allow spamd_t port_t:udp_socket name_bind;
(this bit is the spamassassin resolver issue Steven Stern just reported
for FC4. It was briefly fixed in Rawhide, then regressed to broken stage
with the 2.x policy change)

(generated on a clean fully relabeled system after 3 min of activity)

That's almost the same list I had with selinux-policy-targeted-2.0.0

Regards,

[Daniel J Walsh]

Nicolas Mailhot wrote:
> Le mardi 29 novembre 2005 à 13:23 -0500, Stephen Smalley a écrit :
> > On Tue, 2005-11-29 at 18:56 +0100, Nicolas Mailhot wrote:
> > > Le mardi 29 novembre 2005 à 11:48 -0500, Stephen Smalley a écrit :
> > > > On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote:
> > > > > There are reports in fedora-test about the 2.X policy slowing down
> > > > > udev. (Appears that folks are comparing booting with selinxux=1 with
> > > > > selinux=0).
> > > > >
> > > > > I have to admit that udev is running slower (targeted/enforcing).
> > > > >
> > > > > Any validity to this?  Known issue? How to track down?
> > > >
> > > > First, check whether you have any avc denials associated with udev in
> > > > your audit.log.
> > >
> > > There are certainly many denials with the new 2.0 policy, including udev
> > > stuff (at least it was the case a week ago). I've posted 2.0 audit logs
> > > many times in bugzilla.
> >
> > I think many of those avc issues have been resolved, although there may
> > still be lingering ones.  I think that the udev slowdown is more likely
> > matchpathcon / file_contexts issues.
>
> The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So
> things get (slowly) fixed. But most issues are still there :
>
> audit2allow < /var/log/audit/audit.log
> allow dovecot_auth_t var_lib_t:dir search;
> allow system_chkpwd_t devpts_t:chr_file { read write };
> allow procmail_t spamd_port_t:tcp_socket name_connect;
> allow updfstab_t tmpfs_t:dir getattr;
> allow dovecot_auth_t etc_runtime_t:file read;
> allow spamd_t port_t:udp_socket name_bind;
> (this bit is the spamassassin resolver issue Steven Stern just reported
> for FC4. It was briefly fixed in Rawhide, then regressed to broken stage
> with the 2.x policy change)
>
> (generated on a clean fully relabeled system after 3 min of activity)
>
> That's almost the same list I had with selinux-policy-targeted-2.0.0
>
> Regards,
>
> --
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

selinux-policy-2.0.6-2 should fix most of those.  Available on
ftp://people.redhat.com/dwalsh/SELinux/Fedora

[Nicolas Mailhot]

Le mardi 29 novembre 2005 à 15:01 -0500, Daniel J Walsh a écrit :
> Nicolas Mailhot wrote:
> > The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So
> > things get (slowly) fixed. But most issues are still there :
> >
> > audit2allow < /var/log/audit/audit.log
> > allow dovecot_auth_t var_lib_t:dir search;
> > allow system_chkpwd_t devpts_t:chr_file { read write };
> > allow procmail_t spamd_port_t:tcp_socket name_connect;
> > allow updfstab_t tmpfs_t:dir getattr;
> > allow dovecot_auth_t etc_runtime_t:file read;
> > allow spamd_t port_t:udp_socket name_bind;
> > (this bit is the spamassassin resolver issue Steven Stern just reported
> > for FC4. It was briefly fixed in Rawhide, then regressed to broken stage
> > with the 2.x policy change)
> >
> > (generated on a clean fully relabeled system after 3 min of activity)
> >
> > That's almost the same list I had with selinux-policy-targeted-2.0.0
> selinux-policy-2.0.6-2 should fix most of those.

This one is much better, right. I had to work a little harder to fill my
AVC quota. Now I only get :

# audit2allow < /var/log/audit/audit.log | sort
allow dovecot_auth_t var_auth_t:dir write;
(on-the-fly pam_abl database creation failure, strangely works fine from
ssh)

allow saslauthd_t self:capability setuid;
(should saslauthd be allowed setuid ?)

allow saslauthd_t var_auth_t:dir search;
(more pam_abl stuff)

allow spamd_t port_t:udp_socket name_bind;

Probably related to one of those :

Nov 29 22:08:11 rousalka spamd[2382]: Error creating a DNS resolver
socket: Permission non accordée
at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/DnsResolver.pm
line 202, <GEN5> line 120.
Nov 29 22:08:11 rousalka spamd[2382]: spamd: Error creating a DNS
resolver socket: Permission non accordée
at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/DnsResolver.pm
line 202, <GEN5> line 120.

Nov 29 22:09:38 rousalka spamd[2382]: spamd: connection from
localhost.localdomain [127.0.0.1] at port 50657
Nov 29 22:09:38 rousalka spamd[2382]: spamd: setuid to nim succeeded
Nov 29 22:09:38 rousalka spamd[2382]: spamd: creating
default_prefs: /home/nim/.spamassassin/user_prefs
Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier
existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line
1467
Nov 29 22:09:38 rousalka spamd[2382]: config: cannot write
to /home/nim/.spamassassin/user_prefs: Permission non accordée
Nov 29 22:09:38 rousalka spamd[2382]: spamd: failed to create readable
default_prefs: /home/nim/.spamassassin/user_prefs
Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier
existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line
1467
Nov 29 22:09:38 rousalka spamd[2382]: spamd: checking message
 for nim:500
Nov 29 22:09:38 rousalka spamd[2382]: internal error
Nov 29 22:09:38 rousalka spamd[2382]: pyzor: check failed: internal
error
Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier
existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line
1467
Nov 29 22:09:38 rousalka spamd[2382]: locker: safe_lock: cannot create
tmp
lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accordée
Nov 29 22:09:38 rousalka spamd[2382]: auto-whitelist: open of
auto-whitelist file failed: locker: safe_lock: cannot create tmp
lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accordée
Nov 29 22:09:38 rousalka spamd[2382]: Can't call method "finish" on an
undefined value
at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/Plugin/AWL.pm line
397.
Nov 29 22:09:38 rousalka spamd[2382]: bayes: locker: safe_lock: cannot
create tmp
lockfile /home/nim/.spamassassin/bayes.lock.rousalka.dyndns.org.2382
for /home/nim/.spamassassin/bayes.lock: Permission non accordée

allow system_chkpwd_t devpts_t:chr_file { read write };
(this one is pam-related - may be serious)

allow updfstab_t tmpfs_t:dir getattr;
(fstab-sync is blocked)

Regards,

[Daniel J Walsh]

Nicolas Mailhot wrote:
> Le mardi 29 novembre 2005 à 15:01 -0500, Daniel J Walsh a écrit :
> > Nicolas Mailhot wrote:
> > > The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So
> > > things get (slowly) fixed. But most issues are still there :
> > >
> > > audit2allow < /var/log/audit/audit.log

You should do

audit2allow -l  < /var/log/audit/audit.log

To only get the messages of what AVC messages you got after the last reload.
> > > allow dovecot_auth_t var_lib_t:dir search;
> > > allow system_chkpwd_t devpts_t:chr_file { read write };
> > > allow procmail_t spamd_port_t:tcp_socket name_connect;
> > > allow updfstab_t tmpfs_t:dir getattr;
> > > allow dovecot_auth_t etc_runtime_t:file read;
> > > allow spamd_t port_t:udp_socket name_bind;
> > > (this bit is the spamassassin resolver issue Steven Stern just reported
> > > for FC4. It was briefly fixed in Rawhide, then regressed to broken stage
> > > with the 2.x policy change)
> > >
> > > (generated on a clean fully relabeled system after 3 min of activity)
> > >
> > > That's almost the same list I had with selinux-policy-targeted-2.0.0
> > selinux-policy-2.0.6-2 should fix most of those.
>
> This one is much better, right. I had to work a little harder to fill my
> AVC quota. Now I only get :
>
> # audit2allow < /var/log/audit/audit.log | sort
> allow dovecot_auth_t var_auth_t:dir write;
> (on-the-fly pam_abl database creation failure, strangely works fine from
> ssh)
>
> allow saslauthd_t self:capability setuid;
> (should saslauthd be allowed setuid ?)
>
> allow saslauthd_t var_auth_t:dir search;
> (more pam_abl stuff)
>
> allow spamd_t port_t:udp_socket name_bind;
>
> Probably related to one of those :
>
> Nov 29 22:08:11 rousalka spamd[2382]: Error creating a DNS resolver
> socket: Permission non accordée
> at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/DnsResolver.pm
> line 202, <GEN5> line 120.
> Nov 29 22:08:11 rousalka spamd[2382]: spamd: Error creating a DNS
> resolver socket: Permission non accordée
> at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/DnsResolver.pm
> line 202, <GEN5> line 120.
>
> Nov 29 22:09:38 rousalka spamd[2382]: spamd: connection from
> localhost.localdomain [127.0.0.1] at port 50657
> Nov 29 22:09:38 rousalka spamd[2382]: spamd: setuid to nim succeeded
> Nov 29 22:09:38 rousalka spamd[2382]: spamd: creating
> default_prefs: /home/nim/.spamassassin/user_prefs
> Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier
> existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line
> 1467
> Nov 29 22:09:38 rousalka spamd[2382]: config: cannot write
> to /home/nim/.spamassassin/user_prefs: Permission non accordée
> Nov 29 22:09:38 rousalka spamd[2382]: spamd: failed to create readable
> default_prefs: /home/nim/.spamassassin/user_prefs
> Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier
> existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line
> 1467
> Nov 29 22:09:38 rousalka spamd[2382]: spamd: checking message
>  for nim:500
> Nov 29 22:09:38 rousalka spamd[2382]: internal error
> Nov 29 22:09:38 rousalka spamd[2382]: pyzor: check failed: internal
> error
> Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier
> existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line
> 1467
> Nov 29 22:09:38 rousalka spamd[2382]: locker: safe_lock: cannot create
> tmp
> lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accordée
> Nov 29 22:09:38 rousalka spamd[2382]: auto-whitelist: open of
> auto-whitelist file failed: locker: safe_lock: cannot create tmp
> lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accordée
> Nov 29 22:09:38 rousalka spamd[2382]: Can't call method "finish" on an
> undefined value
> at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/Plugin/AWL.pm line
> 397.
> Nov 29 22:09:38 rousalka spamd[2382]: bayes: locker: safe_lock: cannot
> create tmp
> lockfile /home/nim/.spamassassin/bayes.lock.rousalka.dyndns.org.2382
> for /home/nim/.spamassassin/bayes.lock: Permission non accordée
>
> allow system_chkpwd_t devpts_t:chr_file { read write };
> (this one is pam-related - may be serious)
>
> allow updfstab_t tmpfs_t:dir getattr;
> (fstab-sync is blocked)
>
> Regards,

Please attach the audit.log

[Steve G]

> You should do
>
> audit2allow -l  < /var/log/audit/audit.log

I would like to take this opportunity to point out that you should not be using
the audit logs directly. ausearch is the correct way to access the logs. I would
recommend:

ausearch -m avc,selinux_err | audit2allow -l

There's 3 reasons for this. 1) There may be more than 1 log file that needs to be
examined. ausearch automatically looks at all of them. You can restrict its
search by using the -ts & -te parameters. 2) Sometimes file names or sockets get
encoded and cannot be read without ausearch's interpretation...and 3) we may be
changing to binary log format at some point during fc5/6 time frame.

-Steve

__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

[Stephen Smalley]

On Wed, 2005-11-30 at 05:38 -0800, Steve G wrote:
> > You should do
> >
> > audit2allow -l  < /var/log/audit/audit.log
>
> I would like to take this opportunity to point out that you should not be using
> the audit logs directly. ausearch is the correct way to access the logs. I would
> recommend:
>
> ausearch -m avc,selinux_err | audit2allow -l
>
> There's 3 reasons for this. 1) There may be more than 1 log file that needs to be
> examined. ausearch automatically looks at all of them. You can restrict its
> search by using the -ts & -te parameters. 2) Sometimes file names or sockets get
> encoded and cannot be read without ausearch's interpretation...and 3) we may be
> changing to binary log format at some point during fc5/6 time frame.

Hmm...this should likely get reflected in the audit2allow man page...

[Nicolas Mailhot]

Le mardi 29 novembre 2005 à 18:49 -0500, Daniel J Walsh a écrit :
> Nicolas Mailhot wrote:
> > Le mardi 29 novembre 2005 à 15:01 -0500, Daniel J Walsh a écrit :
> > > Nicolas Mailhot wrote:
> > > > The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So
> > > > things get (slowly) fixed. But most issues are still there :
> > > >
> > > > audit2allow < /var/log/audit/audit.log
>
> You should do
>
> audit2allow -l  < /var/log/audit/audit.log
>
> To only get the messages of what AVC messages you got after the last reload.

Right now my procedure is :
1. install policy
2. touch ./autorelabel
3. init 6
4. init 1
5. mv /var/log/audit/audit.log somewhere_else
6. init 6
7. do some stuff
8. audit2allow

which should be at least as strict of what you propose
> Please attach the audit.log

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172496#c23

Regards,

[Stephen Smalley]

On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote:
> There are reports in fedora-test about the 2.X policy slowing down
> udev. (Appears that folks are comparing booting with selinxux=1 with
> selinux=0).
>
> I have to admit that udev is running slower (targeted/enforcing).
>
> Any validity to this?  Known issue? How to track down?

libselinux 1.27.28 should help with this slowdown, and further
improvement can be had by modifying udev to call
matchpathcon_init_prefix() to limit processing to /dev entries.