pidof -c fails under FC6/strict
by Ted Rule
There appears to be a generic problem with "pidof -c" under SELinux
enforcing which has the side-effect of confusing some of the init.d
scripts.
In particular, the following services - at least - fail to shut down or
report status cleanly:
acpid
hidd
vsftpd
smartd
autofs
mcstrans
syslog-ng ( but not syslogd .. )
The common feature is that these daemons lack a corresponding
/var/run/<daemonname>.pid; in the case of syslog-ng, of course, the real
pid has the "wrong" name.
During shutdown, /etc/init.d/functions:killproc() searches for the
pidfile, and if it fails to find one, it searches for a pid with a
matching exec name via the __pids_pidof() function.
...
# Output PIDs of matching processes, found using pidof
__pids_pidof() {
pidof -c -o $$ -o $PPID -o %PPID -x "$1" || \
pidof -c -o $$ -o $PPID -o %PPID -x "${1##*/}"
}
...
When invoked in SELinux permissive, all is well, and the correct pid is
located, but under enforcing, ( selinux-policy-strict-2.4.6-27 in my
case), "pidof -c" returns a null string. This in turn, causes killproc
to assume that the service is dead.
FWIW, FC4/strict/enforcing is Ok where pidof has a -c option, whilst
RHEL4 doesn't appear to have a -c option to pidof anyway.
The latest pidof appears to use readlink() to compare the value
of /proc/<pid>/exe for any matching pids - older pidof's used stat().
Needless to say, logs don't show any AVC's when I try to run the rogue
pidof calls.
By way of example, one can read the basic process list from sysadm_t,
and then show that pidof -c -x fails where pidof -x works. Similarly,
I've used run_init to emulate the behaviour of the boot scripts running
pidof:
[root@topaz ~]# ps axZ | grep smartd
system_u:system_r:fsdaemon_t 2871 ? S
0:00 /usr/sbin/smartd -q never
staff_u:sysadm_r:sysadm_t 3375 pts/0 R+ 0:00 grep smartd
[root@topaz ~]#
[root@topaz ~]# pidof -x /usr/sbin/smartd
2871
[root@topaz ~]# pidof -x smartd
2871
[root@topaz ~]#
[root@topaz ~]# pidof -c -x /usr/sbin/smartd
[root@topaz ~]# pidof -c -x smartd
[root@topaz ~]# run_init pidof -c -x /usr/sbin/smartd
Authenticating root.
Password:
[root@topaz ~]#
[root@topaz ~]# run_init pidof -x /usr/sbin/smartd
Authenticating root.
Password:
2871
[root@topaz ~]#
As a variant on these tests, I've tried to directly ls and readlink the
exe in question; ls fails to read the symlink and errors, whilst
readlink silently returns with a null.
[root@topaz ~]# ls -ldZ /proc/2871/exe
ls: cannot read symbolic link /proc/2871/exe: Permission denied
lrwxrwxrwx root root system_u:system_r:fsdaemon_t /proc/2871/exe
[root@topaz ~]# run_init ls -ldZ /proc/2871/exe
Authenticating root.
Password:
lrwxrwxrwx root root system_u:system_r:fsdaemon_t /proc/2871/exe
[root@topaz ~]#
[root@topaz ~]# run_init ls -lZ /proc/2871/exe
Authenticating root.
Password:
ls: /proc/2871/exe: Permission denied
[root@topaz ~]# readlink /proc/2871/exec
[root@topaz ~]#
[root@topaz ~]# run_init readlink /proc/2871/exec
Authenticating root.
Password:
[root@topaz ~]#
As a workround for the present, I've simply removed the -c option
from /etc/init.d/functions:__pids_pidof()
I'm currently running:
selinux-policy-strict-2.4.6-27.fc6
kernel-2.6.18-1.2869
SysVinit-2.86-14
Should this be logged as a bug under SELinux policy or SysVinit?
Does this bug affect targeted policy as well?
Is there some simple extra permission which could be granted to initrc_t
and sysadm_t which would let them perform readlink /proc/<pid>/exe, and
hence pidof -c ?
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
17 years, 3 months
Another syslog issue (disable_syslogd_trans interaction)
by Steve Friedman
Another problem that I just discovered with syslog is, with
syslogd_disable_trans=1, /dev/log is labelled device_t and not dev_log_t
(thus breaking a number of other apps). I discovered this with syslog-ng,
but suspect that it will be the same with syslog. (This was BZ'ed as
222195.)
Steve Friedman
17 years, 3 months
Trouble with syslogd and named
by Harley Race
I am using the bind-chroot package in FC6 and am tying
to get named in the chroot to log queries and named
activity to /var/log/named/named.log (outside of the
chroot) via a logging device in the chroot /dev/log.
Selinux is preventing syslogd from creating the device
and genereating the following errors:
type=AVC msg=audit(1168359275.971:7): avc: denied {
search } for pid=1587 comm="syslogd" name="named"
dev=dm-3 ino=10704673
scontext=system_u:system_r:syslogd_t:s0
tcontext=system_u:object_r:name
d_zone_t:s0 tclass=dir
type=SYSCALL msg=audit(1168359275.971:7):
arch=40000003 syscall=10 success=no exit=-13
a0=bfcacf08 a1=1b6 a2=c1e120 a3=bfcab31c items=0
ppid=1586 pid=1587 auid=4294967295 uid=0 gid=0 euid=0
suid=0 f
suid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="syslogd"
exe="/sbin/syslogd"
subj=system_u:system_r:syslogd_t:s0 key=(null)
type=AVC msg=audit(1168359275.995:8): avc: denied {
search } for pid=1587 comm="syslogd" name="named"
dev=dm-3 ino=10704673
scontext=system_u:system_r:syslogd_t:s0
tcontext=system_u:object_r:name
d_zone_t:s0 tclass=dir
type=SYSCALL msg=audit(1168359275.995:8):
arch=40000003 syscall=102 success=no exit=-13 a0=2
a1=bfca8ec0 a2=c1e120 a3=bfcab31c items=0 ppid=1586
pid=1587 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fs
uid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="syslogd"
exe="/sbin/syslogd"
subj=system_u:system_r:syslogd_t:s0 key=(null)
I suppose I could use audit2allow to allow this, but
am wondering why the policy was changed from FC4 to
disable this.
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
17 years, 3 months
sparc64 kernel won't boot with selinux enabled
by Tom Callaway
I'm working on Aurora, which is a rebuild of Fedora Core for SPARC.
Lately, I've been testing with selinux enabled on the targeted policy,
but I haven't gotten very far. When I try to boot on a sparc64, I get
the following (copied by hand, apologies for any typos, I tried to be
accurate):
EXT3-fs: mounted filesystem with ordered data mode.
audit(1168807648.026:2): enforcing=1 old_enforcing=0 auid=4294967295
security: 3 users, 6 roles, 1584 types, 172 bools, 1 sens, 1024 cats
security: 59 classes, 49650 rules
security: class dccp_socket not defined in policy
security: permission dccp_recv in class node not defined in policy
security: permission dccp_send in class node not defined in policy
security: permission dccp_recv in class netif not defined in policy
security: permission dccp_send in class netif not defined in policy
SELinux: Completing initialization
SELinux: Setting up existing superblocks.
SELinux: initialized (dev dm-0, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
SELinux: initialized (dev selinuxfs, type selinuxfs), uses
genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses
genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev eventpollfs, type eventpollfs), uses task SIDs
SELinux: initialized (dev inotifyfs, type inotifyfs), uses
genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
audit(1168807652.930:3): policy loaded auid=4294967295
audit(1168807653.174:4): avc: denied { execmem } for pid=1
comm="init" scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=process
...And there it sits, as init is denied. :)
I found this thread
(http://www.redhat.com/archives/fedora-selinux-list/2005-April/msg00037.html)
while looking through google for other cases of this error message, and
I looked through bugzilla 149819. The sparc64 kernel has
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1, and I tried booting with
"checkreqprot=0", but it does not change the result. Booting with
selinux=permissive works fine. I booted as selinux=permissive and ran
fixfiles relabel, but again, no change seen.
Here are the relevant versions of packages which I have installed:
kernel-2.6.19-1.2906.al3.4.sparc64.rpm
libselinux-1.33.4-2.al3.sparc.rpm
libsemanage-1.9.2-1.al3.sparc.rpm
libsepol-1.15.3-1.al3.sparc.rpm
checkpolicy-1.33.1-2.al3.sparc.rpm
policycoreutils-1.33.12-2.al3.sparc.rpm
selinux-policy-2.4.6-21.al3.noarch.rpm
For obvious reasons (Aurora, like Fedora, enables selinux by default),
I'd like to get this fixed. Any ideas where I should go from here?
Thanks in advance,
~spot
17 years, 3 months
Oddity in evolution.if in selinux-policy-devel-2.4.6-23.fc6.noarch.rpm
by Ted Rule
The recently released devel rpm,
selinux-policy-devel-2.4.6-23.fc6.noarch.rpm, appears to contain an odd
'corruption' in the evolution.if file, viz:
/usr/share/selinux/devel/include/apps/evolution.if
The end of the interface file contains this set of allow statements:
allow staff_evolution_alarm_t staff_t:fifo_file { getattr write };
allow staff_evolution_alarm_t staff_t:unix_stream_socket connectto;
allow staff_evolution_alarm_t staff_tmp_t:dir { add_name getattr search
setattr write };
allow staff_evolution_alarm_t staff_tmp_t:file { getattr lock read
write };
allow staff_evolution_alarm_t staff_tmp_t:sock_file { create write };
allow staff_evolution_alarm_t tmp_t:dir read;
allow staff_evolution_exchange_t staff_t:fd use;
allow staff_evolution_exchange_t staff_t:fifo_file { getattr write };
allow staff_evolution_exchange_t staff_tmp_t:dir { add_name getattr
search setattr write };
allow staff_evolution_exchange_t staff_tmp_t:file { getattr lock read
write };
allow staff_evolution_exchange_t staff_tmp_t:sock_file { create write };
allow staff_evolution_server_t staff_t:fifo_file { getattr write };
allow staff_evolution_server_t staff_t:unix_stream_socket connectto;
allow staff_evolution_server_t staff_tmp_t:dir { add_name getattr search
setattr write };
allow staff_evolution_server_t staff_tmp_t:file { getattr lock read
write };
allow staff_evolution_server_t staff_tmp_t:sock_file { create write };
allow staff_evolution_server_t tmp_t:dir { getattr read search };
allow staff_evolution_t default_t:lnk_file read;
I had previously downloaded the .23 rpm from the testing area, but I
only noticed this today whilst I was trying to build a module to rebuild
my anacron module tweak against the .23 policy, and got this error
message:
[root selinux.local]# make localanacron.pp
Compiling strict localanacron module
/usr/bin/checkmodule: loading policy configuration from
tmp/localanacron.tmp
tmp/all_interfaces.conf:7820:ERROR 'syntax error' at token 'allow' on
line 3871:
allow staff_evolution_alarm_t staff_t:fifo_file { getattr write };
/usr/bin/checkmodule: error(s) encountered while parsing configuration
make: *** [tmp/localanacron.mod] Error 1
[root@topaz selinux.local]#
[root ~]#
The error message corresponds to the first rogue line in the interface
file; once I'd commented out all the lines, my new module compiled Ok. I
checked for any other rogue 'allow' lines in the other interface
definitions, but this appears to be the only set of oddities.
I made a cursory check elsewhere, and the 2.4.6-21.fc7 policy-devel
appears to have the same corruption, whilst the previous stable fc6 rpm,
2.4.6-17.fc6, doesn't.
I've also created BZ #222548 containing these notes.
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
17 years, 3 months
[Fwd: Re: sparc64 kernel won't boot with selinux enabled]
by Karl MacMillan
[Forwarding to the correct list this time]
Tom 'spot' Callaway wrote:
> I'm working on Aurora, which is a rebuild of Fedora Core for SPARC.
> Lately, I've been testing with selinux enabled on the targeted policy,
> but I haven't gotten very far. When I try to boot on a sparc64, I get
> the following (copied by hand, apologies for any typos, I tried to be
> accurate):
>
[CC'ing selinux list]
> EXT3-fs: mounted filesystem with ordered data mode.
> audit(1168807648.026:2): enforcing=1 old_enforcing=0 auid=4294967295
> security: 3 users, 6 roles, 1584 types, 172 bools, 1 sens, 1024 cats
> security: 59 classes, 49650 rules
> security: class dccp_socket not defined in policy
> security: permission dccp_recv in class node not defined in policy
> security: permission dccp_send in class node not defined in policy
> security: permission dccp_recv in class netif not defined in policy
> security: permission dccp_send in class netif not defined in policy
Seems that there is a mismatch between your policy and the kernel.
> SELinux: Completing initialization
> SELinux: Setting up existing superblocks.
> SELinux: initialized (dev dm-0, type ext3), uses xattr
> SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
> SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
> SELinux: initialized (dev selinuxfs, type selinuxfs), uses
> genfs_contexts
> SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
> SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses
> genfs_contexts
> SELinux: initialized (dev devpts, type devpts), uses transition SIDs
> SELinux: initialized (dev eventpollfs, type eventpollfs), uses task SIDs
> SELinux: initialized (dev inotifyfs, type inotifyfs), uses
> genfs_contexts
> SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
> SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
> SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
> SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
> SELinux: initialized (dev proc, type proc), uses genfs_contexts
> SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
> SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
> SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
> audit(1168807652.930:3): policy loaded auid=4294967295
> audit(1168807653.174:4): avc: denied { execmem } for pid=1
> comm="init" scontext=system_u:system_r:kernel_t:s0
> tcontext=system_u:system_r:kernel_t:s0 tclass=process
>
> ...And there it sits, as init is denied. :)
>
Init requiring execmem is surprising to say the least - it certainly
doesn't on i386. Are you seeing a lot of execmem denials in the logs? I
don't really know what is going on, but there is likely a kernel or
compiler / toolchain issue causing overly broad execmem requests.
As a work around you can do (after booting into permissive):
setsebool -P allow_execmem=1
The next reboot will allow this globally and you may get farther in
permissive. You can also change this default in the policy packages.
Karl
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
17 years, 3 months
FlashPlayer 9 Beta refuses to process some Flash content with SELinux enforcing
by Temlakos
Everyone:
Has anyone noticed SELinux to refuse permissions to the Flash Player
plug-in (or standalone)?
And while I'm on the subject: How might I clear one particular
application to do something weird, without having to grant such
clearance to every such application? For example: VideoLAN Client needs
permission to make its memory stack executable. How can I grant such
permission to vlc alone and not across the board?
Temlakos
17 years, 3 months
Postgres directory context
by James Young
Does selinux check context on the whole directory hierarchy when making a
decision about permission to enter a directory? That is, when I try to
access /home/Data/pgsql, will it check the context on /home, then
/home/Data, and then on /home/Data/pgsql? Or will it only check the context
on /home/Data/pgsql?
I want to put a Postgres database in a /home/Data/pgsql/data directory, but
the initrc script will not run it there. I can run it as the postgres user.
The contexts mirror the /var/lib/pgsql/data directory:
user_u:object_r:postgres_db_t. The context of /home/Data/pgsql is
system_u:object_r:var_lib_t.
It does run fine with initrc in /var/lib/pgsql. When I leave the
pgstartup.log in /var/lib/pgsql, I see the errors below. It doesn't matter
whether the database is already initialized or not. The contexts for the
/home/Data/pgsql directory are listed below as well. /home/Data is
system_u:object_r:user_home_dir_t.
I don't see anything in /var/log/audit/audit.log, but I think dontaudit
rules may be in effect.
Does Fedora use the reference policy from Tresys exactly? If not, where can
I find the source policy for Fedora. All I can find are the if files.
Finally, are there any better references for selinux. Everything I've read
seems dated.
Thanks,
Jim Young
pgstartup.log:
-------------------------
could not change directory to "/home/Data/pgsql"
initdb: could not access directory "/home/Data/pgsql/data": Permission
denied
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.
The database cluster will be initialized with locale en_US.UTF-8.
The default database encoding has accordingly been set to UTF8.
postmaster cannot access the server configuration file
"/home/Data/pgsql/data/postgresql.conf": Permission denied
could not change directory to "/home/Data/pgsql"
initdb: could not access directory "/home/Data/pgsql/data": Permission
denied
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.
The database cluster will be initialized with locale en_US.UTF-8.
The default database encoding has accordingly been set to UTF8.
postmaster cannot access the server configuration file
"/home/Data/pgsql/data/postgresql.conf": Permission denied
-----------
directory contexts:
-------------------------------
ls -Zd /home/Data/pgsql
drwx------ postgres postgres system_u:object_r:var_lib_t
/home/Data/pgsql
ls -Z /home/Data/pgsql
drwx------ postgres postgres system_u:object_r:var_lib_t backups
drwx------ postgres postgres system_u:object_r:postgresql_db_t data
-rw------- postgres postgres system_u:object_r:postgresql_log_t
pgstartup.log
ls -Z /home/Data/pgsql/data
drwx------ postgres postgres user_u:object_r:postgresql_db_t base
drwx------ postgres postgres user_u:object_r:postgresql_db_t global
drwx------ postgres postgres user_u:object_r:postgresql_db_t pg_clog
-rw------- postgres postgres user_u:object_r:postgresql_db_t pg_hba.conf
-rw------- postgres postgres user_u:object_r:postgresql_db_t pg_ident.conf
drwx------ postgres postgres user_u:object_r:postgresql_db_t pg_log
drwx------ postgres postgres user_u:object_r:postgresql_db_t pg_multixact
drwx------ postgres postgres user_u:object_r:postgresql_db_t pg_subtrans
drwx------ postgres postgres user_u:object_r:postgresql_db_t pg_tblspc
drwx------ postgres postgres user_u:object_r:postgresql_db_t pg_twophase
-rw------- postgres postgres user_u:object_r:postgresql_db_t PG_VERSION
drwx------ postgres postgres user_u:object_r:postgresql_db_t pg_xlog
-rw------- postgres postgres user_u:object_r:postgresql_db_t
postgresql.conf
-rw------- postgres postgres user_u:object_r:postgresql_db_t
postmaster.opts
17 years, 3 months
Access attempts
by mantaray_1
I was hoping someone could help me to understand what might be happening
to trigger the access attempts I am blocking with my policy which are
listed below. They only seem to appear when I am logged in to the
"Blackboard" program at the university I attend. I have already taken
several steps to limit what my browser can do, and I do not understand
how it can trigger such attempts.
**********************
**********************
Jan 11 15:39:17 schoolhost kernel: audit(1168555157.756:587): avc:
denied { rawip_send } for saddr=192.168.0.2 src=60945
daddr=129.219.10.40 dest=443 netif=eth0
scontext=system_u:system_r:kernel_t:s15:c0.c255
tcontext=system_u:object_r:netif_eth0_t:s0-s15:c0.c255 tclass=netif
Jan 11 15:39:17 schoolhost kernel: audit(1168555157.992:588): avc:
denied { rawip_send } for saddr=192.168.0.2 src=60945
daddr=129.219.10.40 dest=443 netif=eth0
scontext=system_u:system_r:kernel_t:s15:c0.c255
tcontext=system_u:object_r:netif_eth0_t:s0-s15:c0.c255 tclass=netif
Jan 11 15:39:18 schoolhost kernel: audit(1168555158.212:590): avc:
denied { rawip_send } for saddr=192.168.0.2 src=45910
daddr=129.219.10.30 dest=443 netif=eth0
scontext=system_u:system_r:kernel_t:s15:c0.c255
tcontext=system_u:object_r:netif_eth0_t:s0-s15:c0.c255 tclass=netif
Jan 11 15:39:19 schoolhost kernel: audit(1168555159.433:600): avc:
denied { rawip_send } for pid=2465 comm="X" saddr=192.168.0.2
src=60945 daddr=129.219.10.40 dest=443 netif=eth0
scontext=system_u:system_r:kernel_t:s15:c0.c255
tcontext=system_u:object_r:netif_eth0_t:s0-s15:c0.c255 tclass=netif
**********************
**********************
Thanks in advance,
Ken.
17 years, 3 months
more setroubleshoot troubles ;)
by Tom London
Running latest rawhide, targeted enforcing.
Installing latest python-libs (fixes execstack issue in _ctypes.so)
other packages, and rebooting, I get the following AVCs:
type=AVC msg=audit(1167943082.579:7): avc: denied { execute } for
pid=2331 comm="sh" name="ldconfig" dev=dm-0 ino=11337788
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.579:7): arch=40000003 syscall=11
success=no exit=-13 a0=91d4dd8 a1=91d4e58 a2=91d4330 a3=0 items=0
ppid=2330 pid=2331 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) comm="sh" exe="/bin/bash"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(1167943082.646:8): avc: denied { getattr } for
pid=2331 comm="sh" name="ldconfig" dev=dm-0 ino=11337788
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.646:8): arch=40000003 syscall=195
success=no exit=-13 a0=91d4dd8 a1=bfcbee10 a2=47818ff4 a3=0 items=0
ppid=2330 pid=2331 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) comm="sh" exe="/bin/bash"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC_PATH msg=audit(1167943082.646:8): path="/sbin/ldconfig"
type=AVC msg=audit(1167943082.647:9): avc: denied { getattr } for
pid=2331 comm="sh" name="ldconfig" dev=dm-0 ino=11337788
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.647:9): arch=40000003 syscall=195
success=no exit=-13 a0=91d4dd8 a1=bfcbed30 a2=47818ff4 a3=91d4dd8
items=0 ppid=2330 pid=2331 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="sh" exe="/bin/bash"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC_PATH msg=audit(1167943082.647:9): path="/sbin/ldconfig"
type=AVC msg=audit(1167943082.756:10): avc: denied {
execute_no_trans } for pid=2340 comm="ldd" name="ld-2.5.90.so"
dev=dm-0 ino=7209012 scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:ld_so_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.756:10): arch=40000003 syscall=11
success=no exit=-13 a0=8196308 a1=8196988 a2=819cd48 a3=40 items=0
ppid=2339 pid=2340 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) comm="ldd" exe="/bin/bash"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC_PATH msg=audit(1167943082.756:10): path="/lib/ld-2.5.90.so"
type=AVC msg=audit(1167943082.758:11): avc: denied { write } for
pid=2253 comm="setroubleshootd" name="tmp" dev=dm-0 ino=2686977
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1167943082.758:11): arch=40000003 syscall=5
success=no exit=-13 a0=88b4970 a1=280c2 a2=180 a3=280c2 items=0 ppid=1
pid=2253 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) comm="setroubleshootd" exe="/usr/bin/python"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(1167943082.759:12): avc: denied { write } for
pid=2253 comm="setroubleshootd" name="tmp" dev=dm-0 ino=65540
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1167943082.759:12): arch=40000003 syscall=5
success=no exit=-13 a0=8921b50 a1=280c2 a2=180 a3=280c2 items=0 ppid=1
pid=2253 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) comm="setroubleshootd" exe="/usr/bin/python"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(1167943082.759:13): avc: denied { write } for
pid=2253 comm="setroubleshootd" name="tmp" dev=dm-0 ino=65540
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1167943082.759:13): arch=40000003 syscall=5
success=no exit=-13 a0=8921b50 a1=280c2 a2=180 a3=280c2 items=0 ppid=1
pid=2253 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) comm="setroubleshootd" exe="/usr/bin/python"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(1167943082.760:14): avc: denied { unlink } for
pid=2253 comm="setroubleshootd" name="Yp9cip" dev=dm-0 ino=164238
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:root_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.760:14): arch=40000003 syscall=10
success=no exit=-13 a0=88c80c0 a1=1 a2=ae50b4 a3=874f1b0 items=0
ppid=1 pid=2253 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) comm="setroubleshootd"
exe="/usr/bin/python" subj=system_u:system_r:setroubleshootd_t:s0
key=(null)
type=AVC msg=audit(1167943082.765:15): avc: denied { execute } for
pid=2342 comm="sh" name="ldconfig" dev=dm-0 ino=11337788
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.765:15): arch=40000003 syscall=11
success=no exit=-13 a0=8bd4dd8 a1=8bd4e58 a2=8bd4330 a3=0 items=0
ppid=2341 pid=2342 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) comm="sh" exe="/bin/bash"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(1167943082.765:16): avc: denied { getattr } for
pid=2342 comm="sh" name="ldconfig" dev=dm-0 ino=11337788
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.765:16): arch=40000003 syscall=195
success=no exit=-13 a0=8bd4dd8 a1=bfa425c0 a2=47818ff4 a3=0 items=0
ppid=2341 pid=2342 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) comm="sh" exe="/bin/bash"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC_PATH msg=audit(1167943082.765:16): path="/sbin/ldconfig"
type=AVC msg=audit(1167943082.766:17): avc: denied { getattr } for
pid=2342 comm="sh" name="ldconfig" dev=dm-0 ino=11337788
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.766:17): arch=40000003 syscall=195
success=no exit=-13 a0=8bd4dd8 a1=bfa424e0 a2=47818ff4 a3=8bd4dd8
items=0 ppid=2341 pid=2342 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="sh" exe="/bin/bash"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC_PATH msg=audit(1167943082.766:17): path="/sbin/ldconfig"
type=AVC msg=audit(1167943082.782:18): avc: denied {
execute_no_trans } for pid=2345 comm="ldd" name="ld-2.5.90.so"
dev=dm-0 ino=7209012 scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:ld_so_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.782:18): arch=40000003 syscall=11
success=no exit=-13 a0=84f4308 a1=84f4988 a2=84fad48 a3=40 items=0
ppid=2344 pid=2345 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) comm="ldd" exe="/bin/bash"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC_PATH msg=audit(1167943082.782:18): path="/lib/ld-2.5.90.so"
type=AVC msg=audit(1167943082.784:19): avc: denied { write } for
pid=2253 comm="setroubleshootd" name="tmp" dev=dm-0 ino=2686977
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1167943082.784:19): arch=40000003 syscall=5
success=no exit=-13 a0=88c9600 a1=280c2 a2=180 a3=280c2 items=0 ppid=1
pid=2253 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) comm="setroubleshootd" exe="/usr/bin/python"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(1167943082.785:20): avc: denied { write } for
pid=2253 comm="setroubleshootd" name="tmp" dev=dm-0 ino=65540
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1167943082.785:20): arch=40000003 syscall=5
success=no exit=-13 a0=8921b50 a1=280c2 a2=180 a3=280c2 items=0 ppid=1
pid=2253 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) comm="setroubleshootd" exe="/usr/bin/python"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(1167943082.786:21): avc: denied { write } for
pid=2253 comm="setroubleshootd" name="tmp" dev=dm-0 ino=65540
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1167943082.786:21): arch=40000003 syscall=5
success=no exit=-13 a0=8921b50 a1=280c2 a2=180 a3=280c2 items=0 ppid=1
pid=2253 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) comm="setroubleshootd" exe="/usr/bin/python"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(1167943082.787:22): avc: denied { unlink } for
pid=2253 comm="setroubleshootd" name="PRdzmq" dev=dm-0 ino=164259
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:root_t:s0 tclass=file
type=SYSCALL msg=audit(1167943082.787:22): arch=40000003 syscall=10
success=no exit=-13 a0=88d22a0 a1=1 a2=ae50b4 a3=874f1b0 items=0
ppid=1 pid=2253 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) comm="setroubleshootd"
exe="/usr/bin/python" subj=system_u:system_r:setroubleshootd_t:s0
key=(null)
tom
--
Tom London
17 years, 3 months
