[sandbox] modifying the Xephyr window title (patch)
by Christoph A.
Hi,
If most of your windows are sandboxed applications, your bar looks like:
[Sandbox sandbo..] [Sandbox sandbo..] [Sandbox sandbo..]
and it is hard to find a specific application.
example of a current Xephyr title:
Sandbox sandbox_web_t:s0:c112,c991 -- /usr/bin/firefox
with the modification in the attached patch titles will look like:
/usr/bin/firefox (sandbox_web_t)
and it should be easier to find a specific application.
In addition to the type I would find it handy to also include the
DISPLAY in the title (needed when using xsel for copy'n paste).
The second patch only adds '-nolisten tcp' to Xephyr, but if there are
use cases where one needs Xephyr to open a listener this patch will
break thinks.
regards,
Christoph A.
btw: secon's manpage doesn't contain the '-l' option.
11 years, 12 months
sandbox cleanup?
by Christoph A.
Hi,
I just noticed that I have over 100 processes running in the
sandbox_web_client_t domain, although I closed all my sandbox windows.
ps auxZ|grep sandbox_web_client_t|grep -c /usr/libexec/gvfsd
52
ps auxZ|grep sandbox_web_client_t|grep -c '/bin/dbus-daemon --fork
--print-pid 5 --print-address 7 --session'
51
Shouldn't they be killed after I closed all sandbox windows?
Kind regards,
Christoph
13 years
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
13 years
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?
13 years
problem with likewise and audit messages
by Maria Iano
We use targeted SELinux and Likewise Open on our RHEL 5 and CentOS 5
servers, even though Likewise is currently not supported with SELinux
in enforcing mode. Both of them together have been working reliably
for us so far. The audit logs fill up with AVC messages like the ones
I have pasted at the end of this message, which are all regarding /var/
lib/likewise/.lsassd and don't appear to matter from a functional
point of view for the system. I have configured setroubleshoot to send
emails to an internal mailing list when something is blocked, because
apart from the likewise events anything else is really urgent. The
problem is that the list receives so many messages about /var/lib/
likewise/.lsassd that the urgent ones get "lost". I have asked the
folks at Likewise about this and their answer is always that SELinux
should be permissive or disabled.
Is there some way to prevent auditd from logging these AVC messages?
type=AVC msg=audit(1306183684.644:121931): avc: denied { connectto }
for pid=31266 comm="vsftpd" path="/var/lib/likewise/.lsassd"
scontext=system_u:system_r:ftpd_t:s0
tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1306185430.740:122001): avc: denied { write }
for pid=378 comm="pickup" name=".lsassd" dev=dm-1 ino=426071
scontext=system_u:system_r:postfix_pickup_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=sock_file
type=AVC msg=audit(1306179615.139:121656): avc: denied { connectto }
for pid=22431 comm="httpd" path="/var/lib/likewise/.lsassd"
scontext=user_u:system_r:httpd_t:s0
tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=USER_AUTH msg=audit(1306265986.269:124088): user pid=25822 uid=0
auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023
msg='PAM: authentication acct="layout" : exe="/usr/sbin/
sshd" (hostname=asb-sys61.us.ad.gannett.com, addr=10.0.65.242,
terminal=ssh res=failed)'
type=AVC msg=audit(1306853338.309:51215): avc: denied { write } for
pid=5472 comm="genhomedircon" name=".lsassd" dev=dm-4 ino=32827
scontext=user_u:system_r:semanage_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=sock_file
type=AVC msg=audit(1306853338.309:51215): avc: denied { connectto }
for pid=5472 comm="genhomedircon" path="/var/lib/likewise/.lsassd"
scontext=user_u:system_r:semanage_t:s0
tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
Thanks,
Maria
13 years
excluding auditd events
by Mr Dash Four
I am having difficulty in trying to exclude a certain type of messages
for certain SELinux types being reported to the auditd daemon.
In particular, I would like to exclude the following from being reported
(and thus filling up my audit logs unnecessarily):
msgtype={USER_ACCT|CRED_ACQ|USER_START|CRED_DISP|USER_END}
obj_type=crond_t
success=0
When I try to add this as a rule with "auditctl -A exclude,never -F
msgtype=USER_ACCT -F obj_type=crond_t -F success=0" I get "Only msgtype
field can be used with exclude filter" which is a bit daft as I wish to
exclude USER_ACCT message type from being reported *only* for the
"crond_t" SELinux type. Is there any way I can do this?
13 years, 1 month
[sandbox] non permanent '-H'
by Christoph A.
Hi,
I like to run firefox instances where modifications to the profile are
not permanent but with the feature of permanently installed addons,
bookmarks, ...
To accomplish that one can start firefox via
sanbox -X -i ~/.mozilla ....
and it will simply work.
The problem arises if one would like to have different "templates"
sandbox -X -i ~/sandboxes/fftemplate1/.mozilla ...
sandbox -X -i ~/sandboxes/fftemplate2/.mozilla ...
this wont work because the path within the sandbox will also be
~/sandboxes/fftemp.... instead of ~/.mozilla
Is there a way to accomplish what I want?
Or is there something like -H needed with the difference that it
shouldn't store modifications?
kind regards,
Christoph A.
btw: I didn't find a way to tell firefox to look for the profile folder
at a different location.
13 years, 1 month
nagios plugins with state files
by Vadym Chepkov
Hi,
There is a series of nagios plugins which have to record previous call's status in a file.
For example, check_snmp_uptime. It would record the previous uptime of a monitored server into a bdb file and will generate an ERROR state if during a next call uptime was lower then previous.
Unfortunately, there is no suitable context for files like that. even nagios_system_plugin_tmp_t doesn't fit the bill.
# ausearch -m avc -ts today
----
time->Thu May 26 07:13:23 2011
type=SYSCALL msg=audit(1306408403.157:422): arch=40000003 syscall=5 success=yes exit=3 a0=90368a8 a1=80c2 a2=1b6 a3=9026770 items=0 ppid=27717 pid=27718 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null)
type=AVC msg=audit(1306408403.157:422): avc: denied { read write open } for pid=27718 comm="check_snmp_upti" name="__db.t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file
type=AVC msg=audit(1306408403.157:422): avc: denied { create } for pid=27718 comm="check_snmp_upti" name="__db.t100" scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file
type=AVC msg=audit(1306408403.157:422): avc: denied { add_name } for pid=27718 comm="check_snmp_upti" name="__db.t100" scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=dir
type=AVC msg=audit(1306408403.157:422): avc: denied { write } for pid=27718 comm="check_snmp_upti" name="uptime" dev=dm-2 ino=208 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=dir
----
time->Thu May 26 07:13:23 2011
type=SYSCALL msg=audit(1306408403.158:423): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bfdab0b0 a2=541ff4 a3=64 items=0 ppid=27717 pid=27718 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null)
type=AVC msg=audit(1306408403.158:423): avc: denied { getattr } for pid=27718 comm="check_snmp_upti" path="/var/spool/nagios/uptime/__db.t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file
----
time->Thu May 26 07:13:23 2011
type=SYSCALL msg=audit(1306408403.168:424): arch=40000003 syscall=38 success=yes exit=0 a0=93ecf70 a1=90368a8 a2=91b048 a3=64 items=0 ppid=27717 pid=27718 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null)
type=AVC msg=audit(1306408403.168:424): avc: denied { rename } for pid=27718 comm="check_snmp_upti" name="__db.t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file
type=AVC msg=audit(1306408403.168:424): avc: denied { remove_name } for pid=27718 comm="check_snmp_upti" name="__db.t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=dir
----
time->Thu May 26 07:31:48 2011
type=SYSCALL msg=audit(1306409508.204:434): arch=40000003 syscall=195 success=yes exit=0 a0=8cb7c68 a1=bfdf8030 a2=423ff4 a3=64 items=0 ppid=28479 pid=28480 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null)
type=AVC msg=audit(1306409508.204:434): avc: denied { getattr } for pid=28480 comm="check_snmp_upti" path="/var/spool/nagios/uptime/t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file
----
time->Thu May 26 07:31:48 2011
type=SYSCALL msg=audit(1306409508.205:435): arch=40000003 syscall=5 success=yes exit=3 a0=8cb7c68 a1=8002 a2=0 a3=88f5770 items=0 ppid=28479 pid=28480 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null)
type=AVC msg=audit(1306409508.205:435): avc: denied { open } for pid=28480 comm="check_snmp_upti" name="t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file
type=AVC msg=audit(1306409508.205:435): avc: denied { read write } for pid=28480 comm="check_snmp_upti" name="t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file
Did I miss a proper context or I should create a new type?
Thanks,
Vadym
13 years, 1 month
Upgrade F13 -> F14: gdm-session-wor / login denials
by Christoph A.
Hi,
I did an upgrade from f13 to f14 (preupgrade method),
after the reboot network was not working.
My next step was:
touch /.autorelabel
reboot
after the reboot, relabeling took place and after finishing the usual
reboot occurred.
Since the relabeling the machines gdm is not starting anymore.
Logins on the tty (ctrl+alt+F2) are also not working. login attempts
result in an immediate logout.
Booting with selinux=0 as boot option works fine (gdm starts, login works).
In the logfiles one can find these AVCs:
[ 28.919108] type=1400 audit(1306418925.312:5): avc: denied {
entrypoint } for pid=2067 comm="gdm-session-wor"
path="/etc/X11/xinit/Xsession" dev=dm-1 ino=3539578
scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023
tcontext=system_u:object_r:bin_t:s0 tclass=file
gdm-binary[1875]: WARNING: GdmDisplay: display lasted 1.689620 seconds
WARNING: GdmLocalDisplayFactory: maximum number of X display failures
reached: check X server log for errors
kernel: [ 53.017140] type=1400 audit(1306418949.453:11): avc: denied
{ entrypoint } for pid=2227 comm="login" path="/bin/bash" dev=dm-1
ino=262272 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023
tcontext=system_u:object_r:shell_exec_t:s0 tclass=filekernel: [
53.020348] init: tty (/dev/tty2) main process ended, respawning
Any hints how to fix this?
thanks,
Christoph A.
13 years, 1 month
SELinux is preventing /usr/bin/skype from mmap_zero access on the memprotect Unknown.
by Francis Shim
SELinux is preventing /usr/bin/skype from mmap_zero access on the memprotect Unknown.
***** Plugin mmap_zero (53.1 confidence) suggests **************************
If you do not think /usr/bin/skype should need to mmap low memory in the kernel.
Then you may be under attack by a hacker, this is a very dangerous access.
Do
contact your security administrator and report this issue.
***** Plugin catchall_boolean (42.6 confidence) suggests *******************
If you want to control the ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr.
Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean.
Do
setsebool -P mmap_low_allowed 1
***** Plugin catchall (5.76 confidence) suggests ***************************
If you believe that skype should be allowed mmap_zero access on the Unknown memprotect by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep skype /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context unconfined_u:unconfined_r:unconfined_execmem_t:s0-
s0:c0.c1023
Target Context unconfined_u:unconfined_r:unconfined_execmem_t:s0-
s0:c0.c1023
Target Objects Unknown [ memprotect ]
Source skype
Source Path /usr/bin/skype
Port <Unknown>
Host mobile-pc.localdomain
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.9.7-40.fc14
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name mobile-pc.localdomain
Platform Linux mobile-pc.localdomain
2.6.35.13-91.fc14.i686.PAE #1 SMP Tue May 3
13:29:55 UTC 2011 i686 i686
Alert Count 100
First Seen Mon 16 May 2011 03:37:35 PM EDT
Last Seen Mon 16 May 2011 03:37:35 PM EDT
Local ID 162a1493-50dc-4231-ad0f-808d6fe5330b
Raw Audit Messages
type=AVC msg=audit(1305574655.789:127): avc: denied { mmap_zero } for pid=2784 comm="skype" scontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 tclass=memprotect
Hash: skype,unconfined_execmem_t,unconfined_execmem_t,memprotect,mmap_zero
audit2allow
#============= unconfined_execmem_t ==============
#!!!! This avc is allowed in the current policy
allow unconfined_execmem_t self:memprotect mmap_zero;
audit2allow -R
#============= unconfined_execmem_t ==============
#!!!! This avc is allowed in the current policy
allow unconfined_execmem_t self:memprotect mmap_zero;
13 years, 1 month
