On Wed, 2008-07-16 at 16:48 +0000, Justin Mattock wrote: > 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. All you have to do is try it, and you can answer that one yourself: # mount -t selinuxfs none /selinux mount: none already mounted or /selinux busy > And just to let you know, I am not using fstab just was wondering if > things like this > can occur. -- 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.
