On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote: > On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > > > On Tue, 2008-07-15 at 18:17 -0400, Willis Vandevanter wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hello All, > >> > >> I am working on developing a targeted SELinux policy for > >> OpenMoko devices (www.openmoko.org) as a Google Summer Of Code project > >> (http://code.google.com/p/selinux-openmoko/). > >> > >> Background: > >> I have cross-compiled the necessary SELinux code (libselinux-1.34.15, > >> checkpolicy-1.34.7, libsemanage-1.10.9, libsepol-1.16.14, > >> policycoreutils-1.34.16) and devloped a very basic targeted policy. I > >> ported the code on to the device. The policy compiles (make) and > >> installs (make install). > >> > >> Where I am stuck: > >> When cross-compiling libselinux I get some strange behavior. > >> Specifically, I compiled libselinux with the following flags: > >> make > >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/cc ARCH=arm > >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib > >> I then copied the new libselinux.so.1 on to the device. sestatus > >> returns that SELinux is enabled and lists the correct policy version, > >> etc. *BUT* make relabel doesn't work. make relabel (or setfiles) gives > >> the following error: > >> > >> file_contexts/file_contexts: Invalid argument make: *** [relabel] > >> Error 1 > >> The error seems to be that file_contexts is not being interpreted as a > >> regular file (i.e. S_ISREG(sb.st_mode) in setfiles.c is returning 0). > > > > That doesn't seem consistent with the error message; if the S_ISREG() > > test fails, setfiles would send the following output to stderr: > > setfiles: spec file <path> is not a regular file. > > So perhaps you are instead encountering an error on the stat() call that > > precedes the S_ISREG() test, and the perror() output there is what you > > are getting above? > > > > setfiles is built with -D_FILE_OFFSET_BITS=64 by default, and thus uses > > the 64-bit large file system interfaces. But this can be overridden via > > CFLAGS. > > > >> I assume this is because I compiled libselinux without the OpenMoko > >> specific header files (ie with my host-x86 /usr/include rather than > >> the device specific ones), so I re-compiled libselinux: > >> > >> make > >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/ccARCH=arm > >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib > >> INCLUDEDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include > >> I then copied libselinux.so.1 on to the device. setfiles will now > >> correctly label the filesystem, but sestatus now returns SELinux as > >> disabled. I set /etc/selinux/config file to permissive and rebooted, > >> but it is still listed as disabled. > >> > >> How is SELinux determined to be enabled? Could missing or > >> mis-configured header files in the OpenMoko /usr/include cause SELinux > >> to appear as disabled? > > > > SELinux enabled vs disabled is determined based on: > > - presence/absence of selinuxfs in /proc/filesystems, and > > - read of /proc/self/attr/current returns something other than > > "kernel" (i.e. policy has been loaded). > > > > -- > > Stephen Smalley > > National Security Agency > > > > > > -- > > This message was distributed to subscribers of the selinux mailing list. > > If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with > > the words "unsubscribe selinux" without quotes as the message. > > > > Is there a possibility of having the file system mounted twice > i.g. the libraries create /selinux during the boot process > before /etc/fstab, and then once /etc/fstab is called > another mount point in the same vicinity is created? > In my case I was always using debian edgy to install selinux, but > then started to use debian sid; when using sid there is no need to > enter anything in fstab, due to the packages being up to date. > regards; I'm not sure what you are asking. In some distributions, selinuxfs is mounted by /sbin/init. In other distributions, it is mounted by early userspace from initramfs by invoking load_policy -i or directly calling the corresponding libselinux function. Regardless, you don't need it in your fstab file; selinuxfs gets mounted before fstab is ever read normally. As far as enabled/disabled goes, selinuxfs doesn't even have to be presently mounted in the process' namespace; it only needs to be registered in the kernel (as shown by /proc/filesystems) and a policy has to have been previously loaded. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
