SELinux and Shorewall with IPSets
by Mr Dash Four
Problems combining these 2 to run while SELinux is in 'enforced' mode
(policy running is the 'stock' targeted one supplied with FC13). I get 2
audit alerts when Shorewall starts (and fails!) - see logs below. I have
x86_64 arch machine with FC13 running. Stock Shorewall is installed.
IPSet (xtunnels) is compiled in (though with the 'stock' rpm I am
getting the same errors).
The problem seems to be caused by the Shorewall init script (see further
below). The relevant part of my syslog when SELinux is in enforced mode is:
=========SELinux=Enforcing================================
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling...
Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.634:29543):
avc: denied { create } for pid=2577 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.637:29544):
avc: denied { create } for pid=2579 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/zones...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/interfaces...
Jun 26 23:18:38 dev1 shorewall[2456]: Determining Hosts in Zones...
Jun 26 23:18:38 dev1 shorewall[2456]: Preprocessing Action Files...
Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing
/usr/share/shorewall/action.Drop...
Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing
/usr/share/shorewall/action.Reject...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/policy...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/blacklist...
Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: ipset names in Shorewall
configuration files require Ipset Match in your kernel and iptables :
/etc/shorewall/blacklist (line 11)
Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: Shorewall start failed
==========================================================
When I switch SELinux to Permissive I get two further errors:
=========SELinux=Permissive===============================
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29551):
avc: denied { create } for pid=3799 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29552):
avc: denied { getopt } for pid=3799 comm="ipset" lport=255
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29553):
avc: denied { setopt } for pid=3799 comm="ipset" lport=255
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/zones...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/interfaces...
Jun 26 23:32:45 dev1 shorewall[3678]: Determining Hosts in Zones...
Jun 26 23:32:45 dev1 shorewall[3678]: Preprocessing Action Files...
Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing
/usr/share/shorewall/action.Drop...
Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing
/usr/share/shorewall/action.Reject...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/policy...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/blacklist...
Jun 26 23:32:45 dev1 shorewall[3678]: Adding Anti-smurf Rules
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling TCP Flags filtering...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Kernel Route Filtering...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Martian Logging...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 1...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/rules...
Jun 26 23:32:45 dev1 shorewall[3678]: Generating Transitive Closure of
Used-action List...
Jun 26 23:32:45 dev1 shorewall[3678]: Processing
/usr/share/shorewall/action.Reject for chain Reject...
Jun 26 23:32:45 dev1 shorewall[3678]: Processing
/usr/share/shorewall/action.Drop for chain Drop...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 2...
Jun 26 23:32:45 dev1 shorewall[3678]: Applying Policies...
Jun 26 23:32:45 dev1 shorewall[3678]: Generating Rule Matrix...
Jun 26 23:32:45 dev1 shorewall[3678]: Creating iptables-restore input...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling iptables-restore input
for chains blacklst mangle:...
Jun 26 23:32:45 dev1 shorewall[3678]: Shorewall configuration compiled
to /var/lib/shorewall/.start
Jun 26 23:32:45 dev1 shorewall[3678]: Starting Shorewall....
Jun 26 23:32:45 dev1 shorewall[3678]: Initializing...
Jun 26 23:32:46 dev1 kernel: u32 classifier
Jun 26 23:32:46 dev1 kernel: Performance counters on
Jun 26 23:32:46 dev1 kernel: input device check on
Jun 26 23:32:46 dev1 kernel: Actions configured
Jun 26 23:32:46 dev1 shorewall[3678]: Processing /etc/shorewall/init ...
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-x1.ips
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-x2.ips
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-z1.ips
Jun 26 23:32:47 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-z2.ips
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/tcclear ...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Route Filtering...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Martian Logging...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Proxy ARP...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Traffic Control...
Jun 26 23:32:49 dev1 shorewall[3678]: Preparing iptables-restore input...
Jun 26 23:32:49 dev1 shorewall[3678]: Running /sbin/iptables-restore...
Jun 26 23:32:49 dev1 shorewall[3678]: IPv4 Forwarding Enabled
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/start ...
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/started ...
Jun 26 23:32:49 dev1 shorewall[3678]: Shorewall started
==========================================================
The problem seems to be caused by the shorewall init script, which is:
===========Shorewall init script==========================
modprobe ifb numifbs=1
ip link set dev ifb0 up
# configure the ipsets
sw_ips_mask='/etc/shorewall/ips/*.ips'
ipset_exec='/usr/sbin/ipset'
if [ "$COMMAND" = start ]; then
$ipset_exec -F
$ipset_exec -X
for c in `/bin/ls $sw_ips_mask 2>/dev/null`; do
echo loading $c
$ipset_exec -R < $c
done
fi
==========================================================
The above script executes /usr/sbin/ipset to create my IP Sets needed
for running Shorewall (all IP set commands are contained in those *.ips
files). These IP sets comprise mainly of IP subnets which are part of my
blacklists (banned IP subnets), though they also contain some IP Port
sets as well.
Don't know why SELinux denies "create" (and then "getopt" and "setopt")
on a, what seems to be, raw ip socket (IPSet do not use/need one as far
as I know!)? If I remove the IP Set part of the init script above and
rearrange Shorewall to run without IPSets all is well, though its
functionality is VERY limited and barely useful to me!
Two questions to the SELinux gurus on here: 1) Why am I getting these
alerts? and 2) How can I fix the problem so that I could run both
Shorewall and IPSets with SELinux in Enforced mode?
This is important for me as this is a production server and a lot of
stuff runs on it and needs to be available 24/7.
Many thanks in advance!
13 years, 3 months
mysql_upgrade selinux issues
by Luciano Furtado
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Group,
I am seeing the errors (warning since I am on permissive mode) bellow
for mysql_upgrade after I enabled selinux.
Linux lrfurtado 2.6.26-2-xen-686 #1 SMP Thu Nov 25 02:32:31 UTC 2010
i686 GNU/Linux
cat /etc/debian_version
5.0.7
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 23
Policy from config file: default
[ 31.271298] type=1400 audit(1294223212.646:7): avc: denied {
search } for pid=1372 comm="mysql_upgrade" name="bin" dev=xvda
ino=231661 scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=dir
[ 31.285387] type=1400 audit(1294223212.662:8): avc: denied { read
} for pid=1377 comm="mysql_upgrade" name="sh" dev=xvda ino=163914
scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file
[ 31.285413] type=1400 audit(1294223212.662:9): avc: denied {
execute } for pid=1377 comm="mysql_upgrade" name="bash" dev=xvda
ino=163866 scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
[ 31.285423] type=1400 audit(1294223212.662:10): avc: denied {
read } for pid=1377 comm="mysql_upgrade" name="bash" dev=xvda
ino=163866 scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
[ 31.285459] type=1400 audit(1294223212.662:11): avc: denied {
execute_no_trans } for pid=1377 comm="mysql_upgrade" path="/bin/bash"
dev=xvda ino=163866 scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
[ 31.286542] type=1400 audit(1294223212.662:12): avc: denied {
getattr } for pid=1377 comm="sh" path="/bin/bash" dev=xvda ino=163866
scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
[ 31.287663] type=1400 audit(1294223212.662:13): avc: denied {
execute } for pid=1378 comm="sh" name="mysql" dev=xvda ino=231409
scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
[ 31.287678] type=1400 audit(1294223212.662:14): avc: denied {
read } for pid=1378 comm="sh" name="mysql" dev=xvda ino=231409
scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
when I run audit2allow I get the following:
#============= mysqld_t ==============
allow mysqld_t bin_t:dir search;
allow mysqld_t bin_t:file { read execute };
allow mysqld_t bin_t:lnk_file read;
allow mysqld_t shell_exec_t:file { read execute getattr
execute_no_trans };
I have also attached the output of:
sesearch --all | grep mysql > /tmp/mysql.policy
What's the proper fix here? I dont want to give the mysqld_t permission
to execute arbitrary scripts. The only solution I have right now is to
relabel mysql_upgrade so it runs as unconfined, and that's not much of
a solution.
Best Regards.
Luciano
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNMF2mAAoJENgwSj9ZOOwrzbMH/2KBIxOUf68Z/7L1RKAN6pH8
kIIGmcTZRODa5PLTpEIMNPPHij3q2Pmx+nmQk4A0tbWKnmxZORLuEAodwOgZjdg5
pEXqc5SrISid4z5x2hU/x9sXkNaXXUZMXjz+TtdoGQvlAkiwlXZh2YZlcmQAQ2ax
tTrk/sc7KHoHmoDADubsDhbSohj3lqY7hvwTtlLlYQnLnEmwHBPKvr3kQOMS3RDT
4V4Rv5FkrzBRjOJo6FkzwI/UOdR+fIqGkts0L47/R/nSd8cv60IvncpVMqKTaTfY
7f/FfoYGT1w2iKaPx2xingFA8SWXyFQ/8GPKULSEZ3sdSjx+O06UKD6jHet3+oo=
=3Fq0
-----END PGP SIGNATURE-----
13 years, 3 months
nscd AVC
by Vadym Chepkov
Hi,
Is it safe to permit these?
selinux-policy-3.9.7-18.fc14.noarch
# ausearch -m avc -ts yesterday
----
time->Sun Jan 9 11:23:14 2011
type=SYSCALL msg=audit(1294590194.604:12): arch=40000003 syscall=5 success=yes exit=18 a0=57b497 a1=0 a2=1b6 a3=58856a items=0 ppid=1 pid=997 auid=4294967295 uid=28 gid=28 euid=28 suid=28 fsuid=28 egid=28 sgid=28 fsgid=28 tty=(none) ses=4294967295 comm="nscd" exe="/usr/sbin/nscd" subj=system_u:system_r:nscd_t:s0 key=(null)
type=AVC msg=audit(1294590194.604:12): avc: denied { read } for pid=997 comm="nscd" name="/" dev=dm-2 ino=2 scontext=system_u:system_r:nscd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
----
time->Sun Jan 9 11:23:14 2011
type=SYSCALL msg=audit(1294590194.604:13): arch=40000003 syscall=195 success=yes exit=0 a0=57b49c a1=ae2f16bc a2=29fff4 a3=3 items=0 ppid=1 pid=997 auid=4294967295 uid=28 gid=28 euid=28 suid=28 fsuid=28 egid=28 sgid=28 fsgid=28 tty=(none) ses=4294967295 comm="nscd" exe="/usr/sbin/nscd" subj=system_u:system_r:nscd_t:s0 key=(null)
type=AVC msg=audit(1294590194.604:13): avc: denied { read } for pid=997 comm="nscd" name="tmp" dev=dm-0 ino=15581 scontext=system_u:system_r:nscd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=lnk_file
----
time->Sun Jan 9 11:41:04 2011
type=SYSCALL msg=audit(1294591264.449:7): arch=40000003 syscall=195 success=yes exit=0 a0=3f049c a1=ae9f964c a2=38bff4 a3=3 items=0 ppid=1 pid=973 auid=4294967295 uid=28 gid=28 euid=28 suid=28 fsuid=28 egid=28 sgid=28 fsgid=28 tty=(none) ses=4294967295 comm="nscd" exe="/usr/sbin/nscd" subj=system_u:system_r:nscd_t:s0 key=(null)
type=AVC msg=audit(1294591264.449:7): avc: denied { read } for pid=973 comm="nscd" name="tmp" dev=dm-0 ino=15581 scontext=system_u:system_r:nscd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=lnk_file
----
time->Sun Jan 9 11:41:04 2011
type=SYSCALL msg=audit(1294591264.448:6): arch=40000003 syscall=5 success=yes exit=16 a0=3f0497 a1=0 a2=1b6 a3=3fd56a items=0 ppid=1 pid=973 auid=4294967295 uid=28 gid=28 euid=28 suid=28 fsuid=28 egid=28 sgid=28 fsgid=28 tty=(none) ses=4294967295 comm="nscd" exe="/usr/sbin/nscd" subj=system_u:system_r:nscd_t:s0 key=(null)
type=AVC msg=audit(1294591264.448:6): avc: denied { read } for pid=973 comm="nscd" name="/" dev=dm-2 ino=2 scontext=system_u:system_r:nscd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
13 years, 3 months
F14 - NVIDIA & Labels
by Jorge Fábregas
Hi,
Apart from the usual $HOME/.local/share/Trash mislabeled files warnings
I'm getting (same as F12) these for /dev/nvidia* on Fedora 14:
/dev/nvidia0 from system_u:object_r:device_t:s0 to
system_u:object_r:xserver_misc_device_t:s0
/dev/nvidiactl from system_u:object_r:device_t:s0 to
system_u:object_r:xserver_misc_device_t:s0
I don't know...maybe UDEV doesn't have the proper transition rules to
create xserver_misc_device_t on directoy device_t? I fix the labels but
when I restart they're created again with device_t.
The desktop runs fine. It's just that obsession to have all files
properly labeled :)
Regards,
Jorge
13 years, 3 months
Trouble sending mail from PHP scripts
by Scott Gifford
Hello,
I'm having some trouble with an SELinux policy to allow sending mail from a
PHP script run from our Web server with a local installation of qmail on a
CentOS 5 system. We send mail using php's mail() function, which calls
/usr/bin/sendmail, which in turn calls /var/qmail/bin/qmail-inject, then
/var/qmail/bin/qmail-queue, which actually puts the message in the queue.
SELinux comes with some default qmail policies, but out-of-the-box we had
AVC denials when qmail-queue would try to write the message into the queue,
since the Web script context was not permitted to do this.
I decided to take this opportunity to learn about writing SELinux policies.
I know qmail very well, so thought I would write a policy for qmail. The
policy would transition to a new type mail_qmail_queue_t when qmail-queue
was run, and then allow this type to write into the queue.
I think I have the basics working, but I'm running into some snags, and I
don't have enough experience to know what sorts of solutions are likely to
work out.
First, I am seeing some denials that seem to be related to file descriptors
passed by Apache to qmail-queue. When qmail-queue is run, stderr is
connected to the Web server log, and stdout is connected to the HTTP socket.
This is a pretty normal setup, which will cause any output to show up in
the user's browser and errors to show up in the Web server log. However I
get these AVC denials:
- Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
denied { read } for pid=9643 comm="qmail-queue" path="pipe:[4937510]"
dev=pipefs ino=4937510 scontext=system_u:system_r:mail_qmail_queue_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=fifo_file
- Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
denied { append } for pid=9643 comm="qmail-queue"
path="/var/log/httpd/error_log" dev=md2 ino=24183170
scontext=system_u:system_r:mail_qmail_queue_t:s0
tcontext=user_u:object_r:httpd_log_t:s0 tclass=file
- Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
denied { read write } for pid=9643 comm="qmail-queue"
path="socket:[13964]" dev=sockfs ino=13964
scontext=system_u:system_r:mail_qmail_queue_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=tcp_socket
I could write policy to allow mail_qmail_queue access to these httpd_t
resources, but in general it should not have that access; only when it is
run from Apache. I could create a special type for "qmail-queue run from
Apache", but that quickly gets out-of-hand if I create custom policies for
each program that sends mail. What is the normal way to deal with these
sorts of situations?
Second, I am having some trouble getting file contexts set up. I have
several qmail installations with different policies, so I wrote a rule in my
fc file like this:
/var/qmail(-.*)?/bin/qmail-queue --
gen_context(system_u:object_r:mail_qmail_queue_exec_t,s0)
When I use that rule, qmail-queue gets labeled bin_t, I think because of
another rule saying anything in a directory named "bin" is "bin_t". How can
I tell it my rule is more specific or higher priority than the default rule?
For that matter, how can I figure out what rule is overriding mine?
Third, is there a useful guide for troubleshooting SELinux policy execution?
When things don't work as I expect them to, it's hard to find the reason if
it's not obvious from the audit.log.
Finally, can anybody recommend a good book or other resource for learning
SELinux? I have *SELinux by Example*, but it seems that conventions for
policy files have changed a great deal since it was written.
Thanks!
-----Scott.
13 years, 3 months
GIMP help shouldn't need execstack, should it?
by Göran Uddeborg
I discovered recently that gimp help crashes with a segmentation fault
and an execmem AVC denial. I could make it work either by setting
allow_execstack to on, or by changing the type of
/usr/lib64/gimp/2.0/plug-ins/help-browser to
unconfined_execmem_exec_t.
I assume this is a bug in the help-browser that I should report. My
understanding is that execstack should not be needed. But before I do
I thought I check with the knowledgable people here. Is this AVC
denial a result of an application bug, or could it be valid for gimp
help to request this?
13 years, 3 months
Issues logging into to more than one system
by David Highley
Keep getting AVC's when I log into multiple Fedora 14 systems with
automounted home directories. Labels keep getting mucked up after
logging into a client NFS host.
NFS directory server has files located in /export/home/<user>. Have done
semanage fcontext -a -e /home /export/home. They automount to
/home/<user>.
time->Sat Dec 4 15:36:14 2010
type=SYSCALL msg=audit(1291505774.397:17149): arch=c000003e syscall=21
success=no exit=-13 a0=2320f80 a1=6 a2=20 a3=0 items=0 ppid=23814
pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000
egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462
comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker"
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1291505774.397:17149): avc: denied { write } for
pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2
ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:user_home_t:s0 tclass=file
----
time->Sat Dec 4 15:36:14 2010
type=SYSCALL msg=audit(1291505774.397:17150): arch=c000003e syscall=77
success=no exit=-13 a0=c a1=0 a2=7fff53028020 a3=0 items=0 ppid=23814
pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000
egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462
comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker"
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1291505774.397:17150): avc: denied { write } for
pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2
ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:user_home_t:s0 tclass=file
13 years, 4 months
Matlab
by mark
Is there a special policy or guideline for Matlab?
>From the sealert:
Summary:
SELinux is preventing java (httpd_sys_script_t) "getsched" to <Unknown>
(httpd_sys_script_t).
Detailed Description:
[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]
SELinux denied access requested by java. It is not expected that this
access is
required by java and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.
<snip>
mark
13 years, 4 months
Another "execstack" (AviDemux)
by Jorge Fábregas
Hi,
I'm running Fedora 14 (finally) and I'm getting also an "execstack" AVC
while running the Avidemux video editor.
I followed the suggestions on the SELinux Alert Browser and just
copied/pasted the recommended commands to create the local policy:
# grep /usr/bin/avidemux2_gtk /var/log/audit/audit.log | audit2allow -M
mypol
# semodule -i mypol.pp
..but when I run the first line I get:
compilation failed:
mypol.te:6:ERROR 'syntax error' at token '' on line 6:
/usr/bin/checkmodule: error(s) encountered while parsing configuration
/usr/bin/checkmodule: loading policy configuration from mypol.te
Should I open a bug for this issue as well for the execstack one even
though is a package from RPM Fusion ?
The system is totally updated (as of Jan 6th, 2011).
--
Jorge
13 years, 4 months
udev and secure_mode_insmod in selinux-policy-3.9.7-10.fc14 and later
by Mark Montague
Under selinux-policy-3.9.7-7.fc14 and previous, udev was able to load
kernel modules even when secure_mode_insmod=on Starting with the next
policy release, 3.9.7-10.fc14, this fails, resulting in the ethernet
device not being configured when the system boots; no denial is logged.
Setting secure_mode_insmod=off and rebooting results in a working
system, but allows other restricted domains to load kernel modules --
which is a shame since I also have unconfined_login=off and
secure_mode=on. So I added a local module with the following rule in
order to get the 3.9.7-7.fc14 behavior with secure_mode_insmod=on. (The
seemingly superfluous enclosing "if" is needed to avoid a duplicate rule
error).
if (secure_mode_insmod) {
modutils_domtrans_insmod_uncond(udev_t)
}
My question is: what is the desired behavior for future policy
releases? Should secure_mode_insmod=on affect udev as it currently does
under 3.9.7-10.fc14 and later? (A literal reading of the description
for this boolean implies it should). Or should a new boolean be added
(off by default) to allow administrators to have udev load kernel
modules even when secure_mode_insmod=on? Or something else?
Apologies if this is actually a non-issue due to lack of understanding
on my end (but any education would be welcome in that case!)
--
Mark Montague
mark(a)catseye.org
13 years, 4 months
