On Wed, Jul 16, 2008 at 4:56 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > 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 > > oops; I should of thought about that before saying anything. -- 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.
