On 01/29/2016 02:41 PM, Thomas Downing wrote:
On Friday, January 29, 2016 14:25:43 Stephen Smalley wrote:
[snip]
This implies that you haven't loaded a policy into the kernel. Normally
this is done by init; both sysvinit and systemd should already include
the necessary bits but you may have to enable them in your configure.
Okay, my bad, I thought I had done "make load" in
/etc/selinux/refpolicy/src/policy, but I guess I missed that. So now
"seclabel" shows up on all ext4 file systems in /proc/mounts, so that is
good.
Now running "fixfiles -F -f -v -l fixfiles.log relabel" does not complain.
But now I've got two other problems:
1. Looking at the log file produced, only a few files are said to be
labeled, outside of /run/udev, /dev etc. What happened to everything
else in file_contexts?
2. None of the files that the log file claims were relabeled, are in fact
labeled, according to 'ls -Z'.
There is no sysvinit script for selinux stuff for this distro, I need to
create all that. Looking at Fedora 22 that is current SELinux enabled, I
can't find the systemd unit file that does the load, or I would use that
as a reference.
On the other hand, I seems I should be able to use what "make load" does
as a reference as well. Is that a valid assuption?
SELinux initialization is normally done directly from init code, not
from a script file or unit file, because we need init to load policy and
then re-exec itself or dynamically switch contexts to get init into its
own security context (otherwise it will be left in the kernel's domain).
sysvinit and systemd source code already include that support (as does
Android init); if using them, you might just need to rebuild with the
appropriate configure flags.
Alternatively, you could invoke "load_policy -i" from an initramfs
script after switching to the real root and before executing init.
If you run restorecon -v /path/to/file for one of these files that
wasn't labeled, what does it say? What does ls -Z show for the file
before and after?
About init, duh, just not thinking. I will indeed need to rebuild init.
restorecon -v /home/tdowning/.viminfo:
restorecon reset /home/tdowning/.viminfo context
system_u:object_r:user_home_dir_t->system_u:object_r:user_home_t
But ls -aZ:
? .viminfo
(~/.viminfo is the only file under /home that fixfiles even tried to relabel).
It occurs to me that maybe all of fileutils, coreutils,sysutils, libnss*, pam*
and such like might need to be rebuilt? Maybe ls is just not build right. I
note that 'id -Z' complains "works only on an SELinux-enabled kernel",
indicating the need to rebuild all that stuff.
Yes, you need to rebuild your userspace with SELinux enabled. You may
be able to see the actual file context by using getfattr directly, e.g.
getfattr -n security.selinux /path/to/file
I assume you aren't using openembedded / yocto for your appliance?
Because that already has a meta-selinux layer for enabling SELinux support.
_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
