This is after running for a while, occasionally flipping enforcing on and off. Might be interesting to look at.
Bill
/usr/sbin/setfiles -v -n file_contexts/file_contexts `mount | awk '/(ext[23]| xfs).*rw/{print $3}'` /usr/sbin/setfiles: unable to stat file /dev/tty1 /usr/sbin/setfiles: unable to stat file /dev/tty2 /usr/sbin/setfiles: error while labeling files under / /usr/sbin/setfiles: read 1272 specifications /usr/sbin/setfiles: labeling files under / /usr/sbin/setfiles: relabeling /etc/modules.conf from system_u:object_r:etc_t to system_u:object_r:modules_conf_t /usr/sbin/setfiles: relabeling /etc/auto.master from root:object_r:etc_t to system_u:object_r:etc_t /usr/sbin/setfiles: relabeling /etc/ptal/ptal-printd-like from system_u:object_r:etc_runtime_t to system_u:object_r:etc_t /usr/sbin/setfiles: relabeling /etc/hotplug/usb.usermap from system_u:object_r:etc_t to system_u:object_r:hotplug_etc_t /usr/sbin/setfiles: relabeling /etc/mtab from root:object_r:etc_runtime_t to system_u:object_r:etc_runtime_t /usr/sbin/setfiles: relabeling /etc/.pwd.lock from system_u:object_r:shadow_t to system_u:object_r:etc_t /usr/sbin/setfiles: relabeling /etc/security/selinux/src/policy/file_contexts/misc from root:object_r:policy_src_t to system_u:object_r:policy_src_t /usr/sbin/setfiles: relabeling /etc/security/selinux/src/policy/policy.conf from root:object_r:policy_src_t to system_u:object_r:policy_src_t /usr/sbin/setfiles: relabeling /etc/security/selinux/src/policy/tmp/load from root:object_r:policy_src_t to system_u:object_r:policy_src_t /usr/sbin/setfiles: relabeling /etc/security/selinux/src/policy/tmp/program_used_flags.te from root:object_r:policy_src_t to system_u:object_r:policy_src_t /usr/sbin/setfiles: relabeling /etc/security/selinux/src/policy.conf from root:object_r:policy_src_t to system_u:object_r:policy_src_t /usr/sbin/setfiles: relabeling /etc/security/selinux/file_contexts from root:object_r:policy_config_t to system_u:object_r:policy_config_t /usr/sbin/setfiles: relabeling /etc/rndc.key from system_u:object_r:etc_t to system_u:object_r:rndc_conf_t make: *** [checklabels] Error 1
On Thu, 11 Mar 2004 06:18, Bill Nottingham notting@redhat.com wrote:
/usr/sbin/setfiles: relabeling /etc/modules.conf from system_u:object_r:etc_t to system_u:object_r:modules_conf_t
This is a problem. Do you know what might have created that file?
/usr/sbin/setfiles: relabeling /etc/auto.master from root:object_r:etc_t to system_u:object_r:etc_t /usr/sbin/setfiles: relabeling
When you re-create a file the identity will match the identity of the creating process. Presumably you edited the file as root:sysadm_r:sysadm_t. When you relabel /etc after running for some time you see all the files you modified as root.
/etc/ptal/ptal-printd-like from system_u:object_r:etc_runtime_t to system_u:object_r:etc_t /usr/sbin/setfiles: relabeling
How is this file created? Maybe we should put in a file_contexts entry for it? What package(s) use it?
/etc/hotplug/usb.usermap from system_u:object_r:etc_t to system_u:object_r:hotplug_etc_t
I guess that some script created that file.
/etc/hotplug(/.*)? system_u:object_r:hotplug_etc_t
I'll change the hotplug.fc file to have the above and the directory will be labelled as hotplug_etc_t to solve this.
/usr/sbin/setfiles: relabeling /etc/.pwd.lock from system_u:object_r:shadow_t to system_u:object_r:etc_t
/etc/.pwd.lock -- system_u:object_r:shadow_t I'll add the above to types.fc.
/usr/sbin/setfiles: relabeling /etc/rndc.key from system_u:object_r:etc_t to system_u:object_r:rndc_conf_t make: *** [checklabels] Error 1
This is a serious problem. How was the rndc.key file created?
Russell Coker (russell@coker.com.au) said:
/usr/sbin/setfiles: relabeling /etc/modules.conf from system_u:object_r:etc_t to system_u:object_r:modules_conf_t
This is a problem. Do you know what might have created that file?
Bad %post from nfs-utils. It will be fixed in a future build.
/usr/sbin/setfiles: relabeling /etc/auto.master from root:object_r:etc_t to system_u:object_r:etc_t /usr/sbin/setfiles: relabeling
When you re-create a file the identity will match the identity of the creating process. Presumably you edited the file as root:sysadm_r:sysadm_t. When you relabel /etc after running for some time you see all the files you modified as root.
scp'd it, actually. Although, it does point out that we probably need to patch more editors.
/etc/ptal/ptal-printd-like from system_u:object_r:etc_runtime_t to system_u:object_r:etc_t /usr/sbin/setfiles: relabeling
How is this file created? Maybe we should put in a file_contexts entry for it? What package(s) use it?
Tim - this is something to do with hpoj and foomatic?
/usr/sbin/setfiles: relabeling /etc/rndc.key from system_u:object_r:etc_t to system_u:object_r:rndc_conf_t make: *** [checklabels] Error 1
This is a serious problem. How was the rndc.key file created?
%post of bind.
Bill
On Thu, Mar 11, 2004 at 10:10:56AM -0500, Bill Nottingham wrote:
/etc/ptal/ptal-printd-like from system_u:object_r:etc_runtime_t to system_u:object_r:etc_t /usr/sbin/setfiles: relabeling
How is this file created? Maybe we should put in a file_contexts entry for it? What package(s) use it?
Tim - this is something to do with hpoj and foomatic?
Yes, ptal-printd (from hpoj) creates it.
[root@cyberelk root]# cat /etc/ptal/ptal-printd-like # ptal-init tells ptal-printd to use this file as a template for the # security settings (mode, owner and group) for the named pipes in # "/var/run/ptal-printd". The actual contents of this file are # ignored. It was originally created on Tue Dec 2 13:37:14 GMT 2003 # based on "/dev/lp0".
Tim. */
On Fri, 12 Mar 2004 02:10, Bill Nottingham notting@redhat.com wrote:
/usr/sbin/setfiles: relabeling /etc/rndc.key from system_u:object_r:etc_t to system_u:object_r:rndc_conf_t make: *** [checklabels] Error 1
This is a serious problem. How was the rndc.key file created?
%post of bind.
Which program in the bind postinst does this?
Russell Coker (russell@coker.com.au) said:
This is a serious problem. How was the rndc.key file created?
%post of bind.
Which program in the bind postinst does this?
postinstall scriptlet (using /bin/sh): /sbin/chkconfig --add named if [ -f etc/named.boot -a ! -f etc/named.conf ]; then if [ -x /usr/sbin/named-bootconf ]; then cat etc/named.boot | /usr/sbin/named-bootconf > etc/named.conf chmod 644 etc/named.conf fi fi if [ ! -e /etc/rndc.key.rpmnew ]; then sed -e "s/@KEY@/`/usr/sbin/dns-keygen`/" /etc/rndc.key >/etc/rndc.key.tmp mv -f /etc/rndc.key.tmp /etc/rndc.key fi chmod 0640 /etc/rndc.conf etc/rndc.key chown root:named /etc/rndc.conf etc/rndc.key /sbin/ldconfig exit 0
sed & mv, actually.
Bill
On Mon, 2004-03-15 at 09:40, Bill Nottingham wrote:
postinstall scriptlet (using /bin/sh): /sbin/chkconfig --add named if [ -f etc/named.boot -a ! -f etc/named.conf ]; then if [ -x /usr/sbin/named-bootconf ]; then cat etc/named.boot | /usr/sbin/named-bootconf > etc/named.conf chmod 644 etc/named.conf fi fi if [ ! -e /etc/rndc.key.rpmnew ]; then sed -e "s/@KEY@/`/usr/sbin/dns-keygen`/" /etc/rndc.key >/etc/rndc.key.tmp mv -f /etc/rndc.key.tmp /etc/rndc.key fi chmod 0640 /etc/rndc.conf etc/rndc.key chown root:named /etc/rndc.conf etc/rndc.key /sbin/ldconfig exit 0
sed & mv, actually.
Can you add a '/usr/sbin/restorecon etc/rndc.key' (and likewise for any similarly created files)? That should restore the context on it based on the installed file_contexts file.
Stephen Smalley wrote:
On Mon, 2004-03-15 at 09:40, Bill Nottingham wrote:
postinstall scriptlet (using /bin/sh): /sbin/chkconfig --add named if [ -f etc/named.boot -a ! -f etc/named.conf ]; then if [ -x /usr/sbin/named-bootconf ]; then cat etc/named.boot | /usr/sbin/named-bootconf > etc/named.conf chmod 644 etc/named.conf fi fi if [ ! -e /etc/rndc.key.rpmnew ]; then sed -e "s/@KEY@/`/usr/sbin/dns-keygen`/" /etc/rndc.key >/etc/rndc.key.tmp mv -f /etc/rndc.key.tmp /etc/rndc.key fi chmod 0640 /etc/rndc.conf etc/rndc.key chown root:named /etc/rndc.conf etc/rndc.key /sbin/ldconfig exit 0
sed & mv, actually.
Can you add a '/usr/sbin/restorecon etc/rndc.key' (and likewise for any similarly created files)? That should restore the context on it based on the installed file_contexts file.
bind 9-2-3-9 has this patch
if [ -x /usr/sbin/restorecon ]; then # # Restore selinux file_context # /usr/sbin/restorecon /etc/rndc.key fi
On Tue, 16 Mar 2004 01:47, Stephen Smalley sds@epoch.ncsc.mil wrote:
sed & mv, actually.
Can you add a '/usr/sbin/restorecon etc/rndc.key' (and likewise for any similarly created files)? That should restore the context on it based on the installed file_contexts file.
In such cases restorecon is the only option.
In general when developing a package it's easiest to do the following things:
1) Put config files in a sub-directory of /etc whenever possible. Files take their type from the type of the parent directory by default. This means that we get the right label without any effort. Also programs that create files in that directory will not need write permission to etc_t (which may become important in later evolutions of the software).
2) Have a single script that creates the file. If creating the file in question is a relatively common operation then having a script to do it is easiest as we can have domain_auto_trans() rules to give the right context for the script. Of course there is the requirement that when doing a domain_auto_trans() on a script execution the target domain must not be more privileged than the source domain, otherwise you make a security hole. Having a single script to perform an operation generally gives us the best range of options for changing how it works on the SE Linux side with minimum disturbance to the rpm side.
3) Make sure that you create the temporary file in the target directory. mv across file systems is not atomic, and you get type labeling issues. The bind script in question is correct in this regard, but I'm just mentioning it now as it's a common mistake.
selinux@lists.fedoraproject.org