Cannot disable SELinux
by Vratislav Podzimek
Hi, I have a question:
What's the reason for the "Failed to load SELinux policy" displaying on
my booting netbook with "selinux=0" as boot option and also SELinux
disabled in /etc/selinux/config ? (running Fedora 15)
Something doesn't realize that selinux is disabled. How can I prevent
this? It's increasing boot time.
Thanks a lot in advance
Vratislav Podzimek
12 years, 10 months
fedora 14 packagekitd avc messages
by Mike Williams
Hi there. On a fedora 14 system I've been seeing messages from packagekitd
in the audit log.
type=AVC msg=audit(1307117929.373:19540): avc: denied { rlimitinh } for
pid=13147 comm="packagekitd"
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:rpm_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1307117929.373:19540): avc: denied { siginh } for
pid=13147 comm="packagekitd"
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:rpm_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1307117929.373:19540): avc: denied { noatsecure } for
pid=13147 comm="packagekitd"
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:rpm_t:s0-s0:c0.c1023 tclass=process
PackageKit.i686 0.6.12-2.fc14
I did the following and the denied messages have stopped.
audit2allow -i pkg_kit.log -M packagekitd
semodule -i packagekitd.pp
Should I report this as a bug against PackageKit?
If so, is there any other information I should add?
Mike
12 years, 10 months
I wrote up an semanage bash command completion script.
by Daniel J Walsh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If anyone wants to improve it have at it.
I will throw this into the Rawhide policycoreutils.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk3o+DMACgkQrlYvE4MpobON+wCgo89q+zX1W4UfXZFJ+rUAJt4T
2OoAoKTrufvSCtcVHdx02ivDtwY3VZoK
=mm2V
-----END PGP SIGNATURE-----
12 years, 11 months
(not sandboxed) firefox AVCs (execstack)
by Christoph A.
Hi,
by coincidence I saw the following AVCs in my audit log when starting
firefox (firefox runs fine).
type=1400 audit(1307056986.733:2965): avc: denied { execstack } for
pid=13470 comm="plugin-config"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=process
type=1400 audit(1307056986.734:2966): avc: denied { execstack } for
pid=13470 comm="plugin-config"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=process
type=1400 audit(1307056987.922:2967): avc: denied { execstack } for
pid=13465 comm="firefox"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=process
type=1400 audit(1307056987.922:2968): avc: denied { execstack } for
pid=13465 comm="firefox"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=process
type=1400 audit(1307056987.938:2969): avc: denied { execstack } for
pid=13465 comm="firefox"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=process
type=1400 audit(1307056987.938:2970): avc: denied { execstack } for
pid=13465 comm="firefox"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=process
Should I classify these AVCs as suspicious?
rpm -qa selinux*
selinux-policy-targeted-3.9.7-42.fc14.noarch
selinux-policy-3.9.7-42.fc14.noarch
best regards,
Christoph
12 years, 11 months
interesting group of AVCs
by Mr Dash Four
After routine check of my audit logs this morning I found this (capture
with ausearch -i -m AVC):
----
type=SYSCALL msg=audit(30/05/11 01:42:21.687:173) : arch=i386
syscall=socketcall(connect) success=no exit=-115(Operation now in
progress) a0=3 a1=b6dfeb40 a2=55ee30 a3=0 items=0 ppid=1 pid=4308
auid=root uid=_transmission gid=_transmission euid=_transmission
suid=_transmission fsuid=_transmission egid=_transmission
sgid=_transmission fsgid=_transmission tty=(none) ses=1
comm=transmission-da exe=/usr/bin/transmission-daemon
subj=unconfined_u:system_r:transmissionbt_t:s0 key=(null)
type=AVC msg=audit(30/05/11 01:42:21.687:173) : avc: denied { recv }
for pid=4308 comm=transmission-da saddr=xx.xx.xx.xx src=80
daddr=10.x.x.x dest=39322 netif=lo
scontext=unconfined_u:system_r:transmissionbt_t:s0
tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet
----
type=AVC msg=audit(30/05/11 01:42:24.697:174) : avc: denied { recv }
for pid=5716 comm=sh saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x dest=39322
netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0
tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet
----
type=AVC msg=audit(30/05/11 01:42:30.707:175) : avc: denied { recv }
for pid=5820 comm=ipset saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x
dest=39322 netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0
tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet
----
type=AVC msg=audit(30/05/11 01:42:42.727:176) : avc: denied { recv }
for pid=6068 comm=sh saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x dest=39322
netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0
tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet
----
A couple of interesting things:
1. "saddr" is address outside any of my network, so I presume this is
coming in (the avc is "recv"). The destination address, however, is on
one of my interfaces (tun device). What baffles me is that "netif" field
says "lo" which would suggest the loopback interface. How is that possible?
2. The first AVC (173) refers to an attempt at receiving a packet from
outside and this was thwarted (success=no) by my iptables/selinux
packing mechanism. The following 3 AVCs however, have more sinister
look, I think, because they come from two *different* executables:
"comm=sh" (which suggests the command shell?) and "comm=ipset"
(suggesting the ipset command I have on the system). Does that mean an
attempt was made at executing these programs as well as an attempt to
receive packets using these? These 3 logs are a complete mystery to me
as neither the shell (sh) nor ipset have capabilities of sending or
receiving packets over the wire!
3. According to the last 3 logs (174-176), an attempt at receiving
packet was made (and denied) by these executables ("sh" and "ipset")
using destination address of my tun interface (10.x.x.x), but the
interface indicated in those logs is "lo". How is that possible?
12 years, 11 months
Firefox & Sandbox - F14
by Jorge Fábregas
Hello everyone,
F14 (updated to latest) here. It has been a while since I last tried
the sandbox feature. I now went and installed the necessary packages
and tried:
sandbox -X -t sandbox_web_t firefox
but it quits right away. A message on syslog from the kernel facility
shows:
------------------------------------------
avc: denied { execute_no_trans } for pid=4026 comm="xulrunner2"
path="/usr/lib/xulrunner-2/xulrunner"
dev=sda1
ino=393246
scontext=unconfined_u:unconfined_r:sandbox_web_client_t:s0:c538,c991
tcontext=system_u:object_r:lib_t:s0 tclass=file
-------------------------------------------
I didn't get any alert from the SEtroubleshooter...
Should I report a bug?
This is what I'm running:
selinux-policy-targeted-3.9.7-40.fc14.noarch
selinux-policy-3.9.7-40.fc14.noarch
policycoreutils-sandbox-2.0.85-28.fc14.i686
Regards,
Jorge
Thanks,
Jorge
12 years, 11 months
