fcontext nightmare - Help please?
by Edward Harvey
I'm managing an amazon virtual machine, with 8G / partition, and a larger
secondary storage device attached. I enabled selinux, and I'm trying to
make things work (and keep things secure) while migrating some things such
as the ldap & mysql directories to the second device.
As far as I know, simply extending the / partition isn't an option (not LVM)
... Conceivably I could just make a clone larger machine, but there are a
lot of advantages to having the separate storage device... which can be LVM,
and prevents the / filesystem from getting filled up, and can be
detached/reattached to other machines, etc etc. So I'm trying like heck to
keep the second storage device separate.
Here's the problem:
I mount /data, and now I've got to move & preserve things like the
/var/lib/mysql directory to a subdir of /data, while preserving selinux
types and everything. I started out by simply mimicking the / structure ...
sudo mount /data
sudo mkdir -p /data/var/lib
sudo chown --reference=/ /data
sudo chcon --reference=/ /data
sudo chmod --reference=/ /data
sudo chown --reference=/var /data/var
sudo chcon --reference=/var /data/var
sudo chmod --reference=/var /data/var
sudo chown --reference=/var/lib /data/var/lib
sudo chcon --reference=/var/lib /data/var/lib
sudo chmod --reference=/var/lib /data/var/lib
And finally
cd /var/lib ; sudo tar cpf - --selinux mysql | (cd
/data/var/lib ; sudo tar xpf - --selinux) ; cd -
I understand that chcon is not persistent...
And after all the above was done, I meticulously examined all the contexts
of all those directories and confirmed they do match the original...
Unfortunately, as soon as I start mysqld, the context of /data/var/lib/mysql
gets reset. I don't know how or why that is happening, but I presume it's
because I haven't set the fcontext. So ...
I want to write a script that walks through the whole /var/lib/mysql
directory, and creates matching fcontexts for /data/var/lib/mysql. Better
yet ... I would like to create fcontext applied to /data which is a complete
replica of /
Here is where I'm getting stuck. I can do "semanage fcontext -l" and I see
all the information, but it's not in a format that's suitable to modify and
feed back into semanage. I can do "semanage -o -" but it only says
"fcontext -D" which is not helpful.
I can't seem to find any combination of commands that will allow me to get
all the fcontexts of / (or a relatively large subdir of /) and modify them
with the /data prefix to feed back into semanage.
Help please?
Thanks...
11 years, 2 months
F17 yum/rpm not running groupadd in %pre scripts
by Chuck Anderson
Forwarding here since I think this is an SELinux issue w/rpm running
%pre scripts. See the two bugs below.
The "screen" package has this %pre script:
preinstall scriptlet (using /bin/sh):
/usr/sbin/groupadd -g 84 -r -f screen
:
These dontaudit AVCs appear when installing the package via yum and
the group doesn't get created:
# semodule -DB
# yum install screen
...
Running Transaction
Installing : screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64 1/1
warning: group screen does not exist - using root
warning: group screen does not exist - using root
# grep -i avc audit/audit.log
type=AVC msg=audit(1344982418.400:148): avc: denied { read } for pid=5725 comm="groupadd" path="/tmp/tmpdH4tic" dev="dm-5" ino=942811 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:rpm_tmp_t:s0 tclass=file
type=AVC msg=audit(1344982418.400:148): avc: denied { read } for pid=5725 comm="groupadd" path="/tmp/tmpdH4tic" dev="dm-5" ino=942811 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:rpm_tmp_t:s0 tclass=file
type=AVC msg=audit(1344982418.445:149): avc: denied { search } for pid=5725 comm="groupadd" name="contexts" dev="dm-5" ino=672610 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_context_t:s0 tclass=dir
type=AVC msg=audit(1344982418.445:150): avc: denied { search } for pid=5725 comm="groupadd" name="contexts" dev="dm-5" ino=672610 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_context_t:s0 tclass=dir
type=AVC msg=audit(1344982418.445:151): avc: denied { search } for pid=5725 comm="groupadd" name="contexts" dev="dm-5" ino=672610 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_context_t:s0 tclass=dir
Everything works correctly if I "setenforce 0" first.
Thanks.
----- Forwarded message from Chuck Anderson <cra(a)WPI.EDU> -----
Date: Tue, 14 Aug 2012 15:30:33 -0400
From: Chuck Anderson <cra(a)WPI.EDU>
To: For testing and quality assurance of Fedora releases <test(a)lists.fedoraproject.org>
Subject: F17 yum/rpm not running groupadd in %pre scripts
Precedence: list
Reply-To: For testing and quality assurance of Fedora releases <test(a)lists.fedoraproject.org>
I ran into a comedy of errors today after I did a new F17 installation
yesterday. Here are a couple:
https://bugzilla.redhat.com/show_bug.cgi?id=848148
Error in PREIN scriptlet in rpm package wireshark-1.6.9-1.fc17.x86_64
(and why does yum still let the transaction succeed, creating problems
in the RPMDB, broken dependencies?)
https://bugzilla.redhat.com/show_bug.cgi?id=845671
"Directory '/var/run/screen' must have mode 777." when opening screen
(and why does systemd-tmpfiles completely fail to start when there is
a missing group--it should fail gracefully, allowing the other
tmpfiles stuff to run and the service as a whole to run)
Both of these are traceable to missing entries in /etc/group. In the
former cae, there is an explicit "Error in PREIN" script during
instalation. In the latter case, there is only a warning and
installation proceeds:
Running Transaction
Installing : screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64 1/1
warning: group screen does not exist - using root
warning: group screen does not exist - using root
So what is going on with %pre not running groupadd properly? Are there
any known issues in this area?
Thanks.
--
test mailing list
test(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
----- End forwarded message -----
11 years, 2 months
selinux-policy update
by Zdenek Pytela
Hello everyone,
every time I upgrade selinux-policy packages, I get
SELinux is preventing /usr/sbin/load_policy from 'read, append' accesses on
the file /tmp/tmp5vo8of.
Raw Audit Messages
type=AVC msg=audit(1340799402.853:3866): avc: denied { read append } for
pid=22456 comm="load_policy" path="/tmp/tmp5vo8of" dev="tmpfs" ino=464186
scontext=unconfined_u:system_r:load_policy_t:s0-s0:c0.c1023
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1340799402.853:3866): arch=x86_64 syscall=execve
success=yes exit=0 a0=ff5f80 a1=ff5f60 a2=ff2e90 a3=10 items=0 ppid=22449
pid=22456 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts16 ses=357 comm=load_policy exe=/usr/sbin/load_policy
subj=unconfined_u:system_r:load_policy_t:s0-s0:c0.c1023 key=(null)
The command load_policy is executed by the rpm postinstall scriptlet.
It happens on workstations with f16 or f17, the only less usual thing is
that /tmp is mounted as tmpfs with
rw,nodev,noexec,noatime,nodiratime,context=system_u:object_r:tmp_t:s0
Context of /tmp is the same as it was before and the same as physical
directory /var/tmp.
I know how to make local policy rules, but I would like to know if there
is a better solution. Thanks,
--
--Zdenek Pytela, <pytela(a)phil.muni.cz>
11 years, 2 months
semanage 'utf8' error
by Gordon Grant
Hi List
I am trying to install a set of selinux rule definitions, but when I run
# semanage -i ./puppetmaster.pp
to install the rules, I get the following error message:
/usr/sbin/semanage: utf8
I get exit code 1, and my module does not load.
My system is RHEL 6.3 with latest updates.
It is in the 'en_US.UTF-8' locale.
What does this error message mean?
I have tried various LANG env var changes, but can't get the rules to load.
This is the '.te' file which compiles successfully into the
'puppetmaster.pp' file:
module puppetmaster 1.0;
require {
type httpd_passenger_helper_t;
type puppet_var_run_t;
type puppet_log_t;
type puppet_var_lib_t;
type user_devpts_t;
type httpd_t;
type proc_net_t;
type certmonger_t;
class file { rename setattr relabelfrom create write read getattr
relabelto open };
class dir { search setattr relabelfrom create write read getattr
rmdir remove_name relabelto add_name };
class chr_file { read write };
}
#============= certmonger_t ==============
#!!!! The source type 'certmonger_t' can write to a 'dir' of the following
types:
# certmonger_var_lib_t, certmonger_var_run_t, cert_t, dirsrv_config_t,
var_lib_t, var_run_t, root_t
allow certmonger_t puppet_var_lib_t:dir { write search getattr add_name };
#!!!! The source type 'certmonger_t' can write to a 'file' of the following
types:
# certmonger_var_lib_t, certmonger_var_run_t, cert_t, dirsrv_config_t,
root_t
allow certmonger_t puppet_var_lib_t:file { write read create open getattr };
#============= httpd_passenger_helper_t ==============
allow httpd_passenger_helper_t user_devpts_t:chr_file { read write };
#============= httpd_t ==============
allow httpd_t proc_net_t:file { read getattr open };
#!!!! The source type 'httpd_t' can write to a 'dir' of the following types:
# httpd_log_t, dirsrv_config_t, httpd_tmp_t, dirsrvadmin_tmp_t,
httpd_cache_t, httpd_tmpfs_t, httpd_squirrelmail_t, dirsrv_var_log_t,
zarafa_var_lib_t, dirsrv_var_run_t, httpd_var_run_t, dirsrvadmin_config_t,
squirrelmail_spool_t, passenger_var_run_t, httpdcontent,
httpd_cobbler_rw_content_t, httpd_munin_rw_content_t,
httpd_bugzilla_rw_content_t, httpd_cvs_rw_content_t,
httpd_git_rw_content_t, httpd_sys_rw_content_t, httpd_sys_rw_content_t,
httpd_nagios_rw_content_t, httpd_nutups_cgi_rw_content_t,
httpd_apcupsd_cgi_rw_content_t, httpd_mediawiki_rw_content_t,
httpd_squid_rw_content_t, httpd_smokeping_cgi_rw_content_t,
httpd_prewikka_rw_content_t, httpd_dirsrvadmin_rw_content_t,
httpd_w3c_validator_rw_content_t, httpd_awstats_rw_content_t,
httpd_user_rw_content_t
allow httpd_t puppet_log_t:dir { write add_name setattr };
allow httpd_t puppet_log_t:file { write relabelfrom create relabelto };
allow httpd_t puppet_var_lib_t:dir { setattr relabelfrom create write read
rmdir relabelto remove_name add_name };
allow httpd_t puppet_var_lib_t:file { write rename create setattr };
allow httpd_t puppet_var_run_t:dir { search getattr };
thanks,
Gordon
--
Gordon Grant
11 years, 3 months
inode confusion?
by Vadym Chepkov
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
After recent policy upgrade (selinux-policy-targeted-3.10.0-145.fc17.noarch)
I noticed some cron jobs are failing and generate selinux avc:
time->Fri Aug 24 04:02:05 2012
type=SYSCALL msg=audit(1345780925.499:656): arch=c000003e syscall=2 success=no exit=-13 a0=404a07 a1=0 a2=0 a3=0 items=0 ppid=21070 pid=21091 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=85 comm="tmpwatch" exe="/usr/sbin/tmpwatch" subj=system_u:system_r:tmpreaper_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1345780925.499:656): avc: denied { read } for pid=21091 comm="tmpwatch" name="root" dev="dm-1" ino=8194 scontext=system_u:system_r:tmpreaper_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
tmpwatch definitely shouldn't be going to /root home, and I am pretty sure it doesn't.
What's interesting though is this fact:
[root@fedora ~]# ls -ldi /root
8194 dr-xr-x---. 5 root root 4096 Aug 18 15:18 /root
[root@fedora ~]# ls -ldi /var/tmp
8194 drwxrwxrwt. 3 root root 4096 Aug 24 23:41 /var/tmp
both directories have the same inode number, which selinux is complaining about. Since they are on different files system, it's normal:
[root@fedora ~]# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 4.0G 1.1G 2.7G 30% /
devtmpfs 223M 0 223M 0% /dev
tmpfs 244M 0 244M 0% /dev/shm
tmpfs 244M 380K 244M 1% /run
/dev/mapper/vgx-root 4.0G 1.1G 2.7G 30% /
tmpfs 244M 0 244M 0% /sys/fs/cgroup
tmpfs 244M 0 244M 0% /media
/dev/mapper/vgx-home 1008M 34M 923M 4% /home
/dev/mapper/vgx-tmp 504M 17M 462M 4% /tmp
/dev/mapper/vgx-var 1008M 303M 655M 32% /var
/dev/xvda1 504M 94M 386M 20% /boot
But it makes me wonder, if SELinux is confused somehow?
Regards,
Vadym
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlA4F7kACgkQmYV3iqStpjvYYACfcSV/KBMl6lzYM7Y/iASwuQhg
gnEAn3aILGJEjV/Zckc0QY8UqCRpob5V
=fGNj
-----END PGP SIGNATURE-----
11 years, 3 months
fixfiles during yum upgrade
by mark
Maybe I can get a quick answer here - the current upgrade, from CentOS 6.2
to 6.3 frequently seems to invoke fixfiles:
ps -ef | grep fix
root 10140 10126 0 16:58 pts/0 00:00:00 /bin/bash /sbin/fixfiles
-C /etc/selinux/targeted/contexts/files/file_contexts.pre restore
Now, I need to poweroff this server - they're doing power work in the data
center in the morning. Opinions on whether I can just kill that fixfiles,
or do I have to let it run (and this is a home directory and backup
server, so it takes for-bloody-ever to run)?
mark
11 years, 3 months
Daemon started from init script runs as unconfined_u
by Michael Hampton
I am trying to write a SELinux policy for a daemon which will be started from an init script on CentOS 6. I seem to be most of the way there, except when running its init script (with "service bitcoin start"), the daemon starts and runs as unconfined_u:
ps -eZ | grep bitcoin
unconfined_u:system_r:bitcoin_t:s0 19993 ? 00:00:00 bitcoind
I generated the policy using selinux-polgengui which was included with CentOS 6 selecting "Standard Init Daemon".
The init script seems to be correctly labeled:
root@buildbox-el6 ~ # ls -Z /etc/rc.d/init.d/bitcoin
-rwxr-xr-x. root root system_u:object_r:bitcoin_initrc_exec_t:s0 /etc/rc.d/init.d/bitcoin
The daemon also seems to be correctly labeled:
root@buildbox-el6 ~ # ls -Z /usr/sbin/bitcoind
-rwxr-xr-x. root root system_u:object_r:bitcoin_exec_t:s0 /usr/sbin/bitcoind
The bitcoin.if and bitcoin.te are as generated by the tool, though I can provide them if necessary.
I expected the daemon to run as system_u. When the system boots, the daemon is started as system_u as expected, but not when I start or restart it with 'service bitcoin restart'. What's going on here and how do I fix it?
11 years, 3 months
Re: trying to set a context
by mark
Well, I'm slowly beating this into submission. However, an error I'm
seeing now is that selinux doesn't like svn via apache looking at the
repositories. Here's my situation:
/<mybase>/<export dir>/
repoa
repob
lost+found
anotherdir
I don't think that /<mybase>/<export dir>, which is owned root:root,
should have a context of httpd_sys_content_t, but that seems to be what
sealert is telling me.
Is there a clean way to resolve this?
mark
11 years, 3 months
trying to set a context
by mark
Y'know, I know I'm asking for help, but I am so bloody frustrated that I
want to give an example of why most admins I know *loathe* selinux.
chcon doesn't last through reboots. Why? Or why have it?
semanage doesn't offer the most obvious flag: -R, recurse.
I've just restored a subversion repository from backup, after a drive
failed. Now I'm trying to set the context. I'm trying to follow Dan's
instructions in his blog
<http://danwalsh.livejournal.com/28027.html?thread=197755>
semanage fcontext -a -t httpd_sys_content_t 'mipav-svn/(*)'
/etc/selinux/targeted/contexts/files/file_contexts.local: line 5 has
invalid regex mipav-svn/(*): Invalid preceding regular expression
Huh? Ditto without the parens. Nothing's changed. I went back and used
chcon -R, which operates the way I expect a *Nix command to, so that
selinux would shut up. But I want this permanent, so what's the magical
incantation? Do I have the wrong keyboard? Or light a candle?
mark
11 years, 3 months
SELinux: security_context_to_sid error
by Anamitra Dutta Majumdar
We are trying to port over our policies from RHEL5 based CUCM release to RHEL6 based release. We are starting selinux in permissive mode.
When the system comes up during firstboot it gets stuck at a certain point. When we check the syslogs we find that they are empty.
On checking the message buffer we find the following entries
SELinux: security_context_to_sid(system_u:object_r:tmpfs_t) failed for (dev dbcfs, type dbcfs) errno=-22
Kill signal sent to compthread
What could be causing such an error in RHEL6. The same policies work fine on RHEL5.
Any pointers would be greatly appreciated.
Thanks,
Anamitra
11 years, 3 months
