On Wed, Jul 16, 2008 at 3:18 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > 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 > > O.K. I think what I'm trying to say, is if it's possible to have selinux mount itself twice in the same location. i.g. init does it's job, and then later on fstab(if you have an entry in there) will mount as well. In other words once init makes a mount, then fstab tries to make a mount in the same location, will it fail. or mount another selinuxfs on top of the already mounted selinuxfs. And just to let you know, I am not using fstab just was wondering if things like this can occur. regards; -- Justin P. Mattock -- 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.
