transition from init_rc
by Tracy Reed
I think I'm really close to having this policy finished and working, just a
couple things to work out...
When I exercise my app and then run audit2allow and it says:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow myapp_t default_t:dir search;
allow myapp_t default_t:dir read;
allow myapp_t default_t:file execmod;
allow myapp_t myapp_bin_t:file write;
does it mean only the first line is an constraint violation? Or are all of
those constraint violations?
How does one typically deal with constraint violations? By attribute above I
suppose it means a type attribue but how do I know which one to add?
Then I have these:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow initrc_t default_t:file relabelto;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow initrc_t myapp_api_t:file relabelto;
The init script which starts the service relabels the files when the service
starts. I suspect this is a bad idea and I'm not sure why they are doing it. I
think they may be applying security categories here. We may have to find a
different way to approach that.
But how would I allow this if I wanted to?
Similarly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow setfiles_t default_t:file relabelfrom;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow setfiles_t myapp_api_t:file relabelfrom;
etc...
This is all on CentOS 6.5.
Thanks!
--
Tracy Reed
7 years, 9 months
SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm
by Tom Rivers
Hello!
I have posted information regarding the error message I'm seeing at
Github.com in the Pyzor forum located here:
https://github.com/SpamExperts/pyzor/issues/41#issuecomment-135539930
Basically, I was looking at the output of "journalctl -f" on my Fedora
21 system while trying to fine tune SpamAssassin the other day and found
the following:
Aug 27 09:33:16 impact-crater.com spamd[20895]: spamd: processing
message <20150827133258.6E19C61B70D1(a)bastion01.phx2.fedoraproject.org>
for sa-milt:986
Aug 27 09:33:17 impact-crater.com python[22066]: detected unhandled
Python exception in '/usr/bin/pyzor'
Aug 27 09:33:17 impact-crater.com setroubleshoot[7528]: SELinux is
preventing pyzor from getattr access on the file /usr/bin/rpm. For
complete SELinux messages. run sealert -l
09532028-c2c0-472e-b39f-c52ef00c5dc6
Aug 27 09:33:17 impact-crater.com python[7528]: SELinux is preventing
pyzor from getattr access on the file /usr/bin/rpm.
Running the sealert command referenced above yields the following:
SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm.
***** Plugin catchall (100. confidence) suggests
**************************
If you believe that pyzor should be allowed getattr access on the rpm
file 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 pyzor /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:spamc_t:s0
Target Context system_u:object_r:rpm_exec_t:s0
Target Objects /usr/bin/rpm [ file ]
Source pyzor
Source Path pyzor
Port <Unknown>
Host impact-crater.com
Source RPM Packages
Target RPM Packages rpm-4.12.0.1-7.fc21.x86_64
Policy RPM selinux-policy-3.13.1-105.20.fc21.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name impact-crater.com
Platform Linux impact-crater.com
4.1.5-100.fc21.x86_64 #1
SMP Tue Aug 11 00:24:23 UTC 2015 x86_64
x86_64
Alert Count 33
First Seen 2015-08-27 08:35:55 EDT
Last Seen 2015-08-27 09:36:08 EDT
Local ID 09532028-c2c0-472e-b39f-c52ef00c5dc6
Raw Audit Messages
type=AVC msg=audit(1440682568.916:5869): avc: denied { getattr } for
pid=22308 comm="pyzor" path="/usr/bin/rpm" dev="dm-1" ino=1977835
scontext=system_u:system_r:spamc_t:s0
tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file permissive=0
Hash: pyzor,spamc_t,rpm_exec_t,file,getattr
Here is some relevant system info with respect to the system in question:
kernel-4.1.5-100.fc21.x86_64
pyzor-0.5.0-10.fc21.noarch
Python 2.7.8 (default, Apr 15 2015, 09:26:43)
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux2
One of the guys at Github who initially responded indicated that,
"There's nothing in Pyzor that would try to access /usr/bin/rpm."
Evidently SELinux is upset at something so I figured it would be a good
idea to also post on this list to see if anyone here knows anything I
can do to help identify what's happening.
Thanks!
Tom
8 years
Unable to login with targeted policy, enforcing mode
by Srinivasa Rao Ragolu
Hi All,
I am new to selinux stuff and I am trying to port selinux to embedded
platform using meta-selinux layer from yocto project (
http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/tree/?h=dizzy)
*Problem:*
Not able to login with root user. root user is not acceptable while booting
in enforcing mode of targeted policy.
*Observations:*
with permissive mode, was able to login and captured below details. Using
sysvinit as init manager.
*#ps*
714 root 4920 S /lib/udev/udevd -d
825 root 4916 S /lib/udev/udevd -d
826 root 4916 S /lib/udev/udevd -d
1022 root 2172 S {udhcpc} /bin/busybox /sbin/udhcpc -R -n -p
/var/run
1039 messageb 11204 S /usr/bin/dbus-daemon --system
1043 distcc 3124 S N /usr/bin/distccd --pid-file=/var/run/distcc.pid
--da
1044 distcc 3124 S N /usr/bin/distccd --pid-file=/var/run/distcc.pid
--da
1051 root 2172 S {syslogd} /bin/busybox /sbin/syslogd -n -O
/var/log/
1054 root 2172 S {klogd} /bin/busybox /sbin/klogd -n
1057 distcc 3124 S N /usr/bin/distccd --pid-file=/var/run/distcc.pid
--da
1060 avahi 3172 S avahi-daemon: running [arm-cortex-a15.local]
1061 avahi 3172 S avahi-daemon: chroot helper
1072 distcc 3124 S N /usr/bin/distccd --pid-file=/var/run/distcc.pid
--da
1076 root 3544 S /bin/login --
1078 root 0 SW [kauditd]
1080 root 3020 S -sh
1081 root 2504 R {ps} /bin/busybox /bin/ps
*#sestatus -v*
root@arm-cortex-a15:~# sestatus -v
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
Process contexts:
Current context:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Init context: system_u:system_r:init_t:s0
File contexts:
Controlling terminal: unconfined_u:object_r:user_tty_device_t:s0
/etc/passwd system_u:object_r:etc_t:s0
/etc/shadow system_u:object_r:shadow_t:s0
/bin/bash system_u:object_r:shell_exec_t:s0
/bin/login system_u:object_r:bin_t:s0 ->
system_u:object_r:login_exec_t:s0
/bin/sh system_u:object_r:bin_t:s0 ->
system_u:object_r:shell_exec_t:s0
/sbin/init system_u:object_r:bin_t:s0 ->
system_u:object_r:init_exec_t:s0
/lib/libc.so.6 system_u:object_r:lib_t:s0 ->
system_u:object_r:lib_t:s0
*root@arm-cortex-a15:~# sesearch -T -t login_exec_t *
Found 3 semantic te rules:
type_transition rlogind_t login_exec_t : process remote_login_t;
type_transition telnetd_t login_exec_t : process remote_login_t;
type_transition getty_t login_exec_t : process local_login_t;
*root@arm-cortex-a15:~# sesearch -T -t getty_exec_t *
Found 2 semantic te rules:
type_transition init_t getty_exec_t : process getty_t;
type_transition initrc_t getty_exec_t : process getty_t;
*root@arm-cortex-a15:~# grep getty_exec_t
/etc/selinux/targeted/contexts/files/file-contexts*
/sbin/.*getty -- system_u:object_r:getty_exec_t:s0
root@arm-cortex-a15:~#
policy rules in /etc/selinux/targeted/contexts/files/file-contexts are
/bin/bash -- system_u:object_r:shell_exec_t:s0
/bin/login -- system_u:object_r:login_exec_t:s0
/bin/d?ash -- system_u:object_r:shell_exec_t:s0
/sbin/.*getty -- system_u:object_r:getty_exec_t:s0
As of now I am completely struck. Please help me to resolve this issue.
What modifications are needed to login as root under targeted policy and
enforcing mode?
Thanks and Regards,
Srinivas.
8 years
sVirt and shared disk
by Luc de Louw
Hi there,
Quoting https://libvirt.org/drvqemu.html
"Disks that are marked as <shared> will get a generic label
system_u:system_r:svirt_image_t:s0 allowing all guests read/write access
them"
The problem now is that the shared disks can potentially being accessed
by other VMs which is not really nice.
Is it safe to remove the shared parameter in the libvirt config and use
static labeling instead?
Thanks,
Luc
8 years
Please help me in resolving this issue
by Srinivasa Rao Ragolu
Hi All,
I have very new to selinux. Today I have ported selinux to my embedded
platform with targeted policy+enforcing.
When I try to boot, it completes labeling filesystem. But I could not able
to login using root.. See my error log...
*arm-cortex-a15 login: root*
*Last login: Tue Aug 18 11:36:58 UTC 2015 on console*
*Would you like to enter a security context? [N] Y*
*role: unconfined_r*
*level: s0*
*[ 1252.885468] type=1400 audit(1439898856.140:13): avc: denied {
transition } for pid=1120 comm="login" path="/bin/bash" dev="mmcblk0"
ino=58115 scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process*
*[ 1252.887219] type=1400 audit(1439898856.140:14): avc: denied {
transition } for pid=1120 comm="login" path="/bin/bash" dev="mmcblk0"
ino=58115 scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process*
*Cannot execute /bin/sh: Permission denied*
*MontaVista Carrier Grade Linux 7.0.0 arm-cortex-a15 /dev/console*
*arm-cortex-a15 login:*
Please help me.. How can I solve this issue and achieve normal boot.
Thanks,
Srinivas.
8 years, 1 month
bacula-fd and relabelto
by Bill shirley
After recently upgrading my server to Fedora 22, I ran a bacula restore which generated a
whole bunch of AVCs. I created a policy and ran another restore which generated more
AVCs. After looking at the new audit2allow output:
module my_bacula-fd.more 1.0;
require {
type user_home_dir_t;
type home_root_t;
type user_home_t;
type samba_share_t;
type bacula_t;
class file relabelto;
class dir { write relabelto };
}
#============= bacula_t ==============
#!!!! WARNING: 'home_root_t' is a base type.
allow bacula_t home_root_t:dir relabelto;
allow bacula_t samba_share_t:dir relabelto;
allow bacula_t samba_share_t:file relabelto;
allow bacula_t user_home_dir_t:dir relabelto;
allow bacula_t user_home_t:dir write;
#!!!! This avc is a constraint violation. You would need to modify the attributes of either the source or target types to allow
this access.
#Constraint rule:
# constrain dir { create relabelfrom relabelto } ((u1 == u2 -Fail-) or (t1 == can_change_object_identity -Fail-) );
Constraint DENIED
# Possible cause is the source user (system_u) and target user (unconfined_u) are different.
allow bacula_t user_home_t:dir relabelto;
#!!!! This avc is a constraint violation. You would need to modify the attributes of either the source or target types to allow
this access.
#Constraint rule:
# constrain file { create relabelfrom relabelto } ((u1 == u2 -Fail-) or (t1 == can_change_object_identity -Fail-) );
Constraint DENIED
# Possible cause is the source user (system_u) and target user (unconfined_u) are different.
allow bacula_t user_home_t:file relabelto;
I realized I was chasing my tail trying to generate a policy for this.
home_root_t is because I'm restoring a user's home directory and bacula-fd has to create
/bacula/bacula-restores/home. Also note that I've moved the default restore location to
/bacula/bacula-restores because my first attempt to /tmp filled it up and the world stopped.
It seems to me that bacula-fd should run unconfined to that it can relabel the files it restores.
Note, bacula-fd is different that its cousins bacula-dir and bacula-sd because those two don't
need access to everything.
I thought of changing /usr/sbin/bacula-fd to unconfined_t but then if bacula-fd is ever upgraded
it will break again.
What's the best way to handle this?
Bill Shirley
8 years, 1 month
mod_selinux denial with httpd
by William Brown
Hi,
I'm trying to work on getting mod_selinux into EPEL.
When testing this, I noticed the following denial:
type=AVC msg=audit(1438573551.889:484): avc: denied { setcurrent } for
pid=4988 comm="httpd" scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=process
What's the best approach to getting this into the selinux policy for rhel /
mod_selinux? Should this be a boolean that you need to enable? Given the ability
to change process context is powerful, I don't think it should be a default.
Or should mod_selinux have this as a boolean, and define some extra types to
transition down into to help make this a more secure default?
Your advice is appreciated.
Sincerely,
--
William Brown <william(a)blackhats.net.au>
8 years, 1 month
