From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6FMHQ47028620 for ; Tue, 15 Jul 2008 18:17:26 -0400 Received: from nf-out-0910.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6FMHPMO023043 for ; Tue, 15 Jul 2008 22:17:26 GMT Received: by nf-out-0910.google.com with SMTP id b21so2149057nfd.4 for ; Tue, 15 Jul 2008 15:17:24 -0700 (PDT) Message-ID: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> Date: Tue, 15 Jul 2008 18:17:24 -0400 From: "Willis Vandevanter" To: selinux@tycho.nsa.gov Subject: OpenMoko/JFFS2 sestatus difficulties MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15993_27822822.1216160244524" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov ------=_Part_15993_27822822.1216160244524 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline -----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). 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? I apologize for the long email. The policy I am using is available at http://code.google.com/p/selinux-openmoko/. The cross-compiled binaries are also available. I am using a 2.6.24.7 kernel with SELinux and JFFS2 XATTR enabled. Thank you for your help, Willis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIfSH2qCokMvr1WNARAuJdAJ0Q9iWp7+V0jTxen92WfE8RFnpJeACgiRyX vAFzngclbVPHIZ/YckQi3Sg= =P7dW -----END PGP SIGNATURE----- ------=_Part_15993_27822822.1216160244524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
-----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).
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?

I apologize for the long email. The policy I am using is available at
http://code.google.com/p/selinux-openmoko/. The cross-compiled
binaries are also available. I am using a 2.6.24.7 kernel with SELinux
and JFFS2 XATTR enabled.

Thank you for your help,
  Willis

 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIfSH2qCokMvr1WNARAuJdAJ0Q9iWp7+V0jTxen92WfE8RFnpJeACgiRyX
vAFzngclbVPHIZ/YckQi3Sg=
=P7dW
-----END PGP SIGNATURE-----


------=_Part_15993_27822822.1216160244524-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6G0sO4h017455 for ; Tue, 15 Jul 2008 20:54:24 -0400 Received: from tyo202.gate.nec.co.jp (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6G0sMHv023670 for ; Wed, 16 Jul 2008 00:54:23 GMT Message-ID: <487D46B5.9070608@ak.jp.nec.com> Date: Wed, 16 Jul 2008 09:54:13 +0900 From: KaiGai Kohei MIME-Version: 1.0 To: Willis Vandevanter CC: selinux@tycho.nsa.gov, ynakam@hitachisoft.jp Subject: Re: OpenMoko/JFFS2 sestatus difficulties References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> In-Reply-To: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Willis, I guess selinuxfs is not mounted. In SELinux environment, /sbin/init is extended to mount selinuxfs on /selinux. It enables to communicate between kernel and userspaces. If your /sbin/init is implemented using busybox, consider to turn on "SELinux support" option and make /selinux directory on your jffs2 image. 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, Is it your host environment, isn't it? > 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). > 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? > > I apologize for the long email. The policy I am using is available at > http://code.google.com/p/selinux-openmoko/. The cross-compiled > binaries are also available. I am using a 2.6.24.7 > kernel with SELinux > and JFFS2 XATTR enabled. > > Thank you for your help, > Willis > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIfSH2qCokMvr1WNARAuJdAJ0Q9iWp7+V0jTxen92WfE8RFnpJeACgiRyX > vAFzngclbVPHIZ/YckQi3Sg= > =P7dW > -----END PGP SIGNATURE----- -- OSS Platform Development Division, NEC KaiGai Kohei -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6G3DaWI002763 for ; Tue, 15 Jul 2008 23:13:36 -0400 Received: from wx-out-0506.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6G3DZHv019618 for ; Wed, 16 Jul 2008 03:13:36 GMT Received: by wx-out-0506.google.com with SMTP id i26so2597458wxd.30 for ; Tue, 15 Jul 2008 20:13:35 -0700 (PDT) Message-ID: Date: Wed, 16 Jul 2008 03:13:35 +0000 From: "Justin Mattock" To: "KaiGai Kohei" Subject: Re: OpenMoko/JFFS2 sestatus difficulties Cc: "Willis Vandevanter" , selinux@tycho.nsa.gov, ynakam@hitachisoft.jp In-Reply-To: <487D46B5.9070608@ak.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <487D46B5.9070608@ak.jp.nec.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, Jul 16, 2008 at 12:54 AM, KaiGai Kohei wrote: > Willis, > > I guess selinuxfs is not mounted. > > In SELinux environment, /sbin/init is extended to mount selinuxfs > on /selinux. It enables to communicate between kernel and userspaces. > > If your /sbin/init is implemented using busybox, consider to turn on > "SELinux support" option and make /selinux directory on your jffs2 image. > > > 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, > > Is it your host environment, isn't it? > >> 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). >> 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? >> >> I apologize for the long email. The policy I am using is available at >> http://code.google.com/p/selinux-openmoko/. The cross-compiled >> binaries are also available. I am using a 2.6.24.7 >> kernel with SELinux >> and JFFS2 XATTR enabled. >> >> Thank you for your help, >> Willis >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQFIfSH2qCokMvr1WNARAuJdAJ0Q9iWp7+V0jTxen92WfE8RFnpJeACgiRyX >> vAFzngclbVPHIZ/YckQi3Sg= >> =P7dW >> -----END PGP SIGNATURE----- > > -- > OSS Platform Development Division, NEC > KaiGai Kohei > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov > with > the words "unsubscribe selinux" without quotes as the message. > Hello;(don't mean to jump in) make sure fstab has it entry to mount SELinux, and do a ldd /sbin/init you should see libsepol, and libselinux if not install sysvinit this way the policy is loaded early in the boot process, with its libraries, in grub.conf put selinux=1 enforcing=1/0 <~~~1=on 0=off then watch all of the audit messages. 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6G5Fpfj017490 for ; Wed, 16 Jul 2008 01:15:51 -0400 Received: from nf-out-0910.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6G5FnmS012854 for ; Wed, 16 Jul 2008 05:15:50 GMT Received: by nf-out-0910.google.com with SMTP id b21so2198284nfd.4 for ; Tue, 15 Jul 2008 22:15:49 -0700 (PDT) Message-ID: <4c63b15c0807152215p271dc8e6m1854ab006245b35@mail.gmail.com> Date: Wed, 16 Jul 2008 01:15:48 -0400 From: "Willis Vandevanter" To: selinux@tycho.nsa.gov Subject: Re: OpenMoko/JFFS2 sestatus difficulties Cc: "KaiGai Kohei" , ynakam@hitachisoft.jp In-Reply-To: <487D46B5.9070608@ak.jp.nec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19823_14813194.1216185348986" References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <487D46B5.9070608@ak.jp.nec.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov ------=_Part_19823_14813194.1216185348986 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline KaiGai said: > I guess selinuxfs is not mounted. I unmounted and remounted /selinux after I copied the new libselinux.so.1 onto the device. sestatus still returns disabled. I also have the following in /etc/fstab: > selinux /selinux selinuxfs noauto 0 0 KaiGai said: > If your /sbin/init is implemented using busybox, consider to turn on > "SELinux support" option > /sbin/init is implemented using busybox, but I'm not sure if the SELinux support option is turned on. I will have to check on this in the morning. Russell said: > What exactly is the output of "sestatus"? The output of sestatus is: > SELinux status: disabled Justin said: > do a ldd /sbin/init, you should see libsepol, and libselinux if not install > sysvinit > The output from ldd /sbin/init is: > libc.so.6 => /lib/libc.so.6 (0x40025000) > /lib/ld-linux.so.3 (0x40000000) > Oddly enough this is also the output when sestatus reports SELinux as enabled. sysvinit is installed. in grub.conf put selinux=1 enforcing=1/0 <~~~1=on 0=off > I rebooted with the boot parameters appended, but still sestatus reports SELinux as disabled. Even stranger is dmesg has the following: .... > Security Framework initialized > SELinux: Initializing. > SELinux: Starting in permissive mode > ....... > SELinux: Registering netfilter hooks > io scheduler noop registered > io scheduler deadline registered (default) > ...... > It is late here right now =)). I will try the strace on sestatus tomorrow morning. -Willis On Tue, Jul 15, 2008 at 8:54 PM, KaiGai Kohei wrote: > Willis, > > I guess selinuxfs is not mounted. > > In SELinux environment, /sbin/init is extended to mount selinuxfs > on /selinux. It enables to communicate between kernel and userspaces. > > If your /sbin/init is implemented using busybox, consider to turn on > "SELinux support" option and make /selinux directory on your jffs2 image. > > > 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, >> > > Is it your host environment, isn't it? > > 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). >> 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? >> >> I apologize for the long email. The policy I am using is available at >> http://code.google.com/p/selinux-openmoko/. The cross-compiled >> binaries are also available. I am using a 2.6.24.7 >> kernel with SELinux >> and JFFS2 XATTR enabled. >> >> Thank you for your help, >> Willis >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQFIfSH2qCokMvr1WNARAuJdAJ0Q9iWp7+V0jTxen92WfE8RFnpJeACgiRyX >> vAFzngclbVPHIZ/YckQi3Sg= >> =P7dW >> -----END PGP SIGNATURE----- >> > > -- > OSS Platform Development Division, NEC > KaiGai Kohei > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith > the words "unsubscribe selinux" without quotes as the message. > ------=_Part_19823_14813194.1216185348986 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
KaiGai said:
I guess selinuxfs is not mounted.

I unmounted and remounted /selinux after I copied the new libselinux.so.1 onto the device. sestatus still returns disabled.

I also have the following in /etc/fstab:
selinux                /selinux        selinuxfs       noauto  0       0

KaiGai said:
If your /sbin/init is implemented using busybox, consider to turn on
"SELinux support" option

/sbin/init is implemented using busybox, but I'm not sure if the SELinux support option is turned on.  I will have to check on this in the morning.

Russell said:
What exactly is the output of "sestatus"?

The output of sestatus is:
SELinux status:                 disabled

Justin said:
do a ldd /sbin/init, you should see libsepol, and libselinux if not install sysvinit

The output from ldd /sbin/init is:
    libc.so.6 => /lib/libc.so.6 (0x40025000)
    /lib/ld-linux.so.3 (0x40000000)

Oddly enough this is also the output when sestatus reports SELinux as enabled. sysvinit is installed.

in grub.conf put selinux=1 enforcing=1/0  <~~~1=on 0=off

I rebooted with the boot parameters appended, but still sestatus reports SELinux as disabled. Even stranger is dmesg has the following:

....
Security Framework initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
.......
SELinux:  Registering netfilter hooks
io scheduler noop registered
io scheduler deadline registered (default)
......


It is late here right now =)). I will try the strace on sestatus tomorrow morning.

-Willis
 
On Tue, Jul 15, 2008 at 8:54 PM, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
Willis,

I guess selinuxfs is not mounted.

In SELinux environment, /sbin/init is extended to mount selinuxfs
on /selinux. It enables to communicate between kernel and userspaces.

If your /sbin/init is implemented using busybox, consider to turn on
"SELinux support" option and make /selinux directory on your jffs2 image.


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 <http://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,

Is it your host environment, isn't it?

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).
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?

I apologize for the long email. The policy I am using is available at
http://code.google.com/p/selinux-openmoko/. The cross-compiled
binaries are also available. I am using a 2.6.24.7 <http://2.6.24.7> kernel with SELinux

and JFFS2 XATTR enabled.

Thank you for your help,
 Willis

 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIfSH2qCokMvr1WNARAuJdAJ0Q9iWp7+V0jTxen92WfE8RFnpJeACgiRyX
vAFzngclbVPHIZ/YckQi3Sg=
=P7dW
-----END PGP SIGNATURE-----

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

------=_Part_19823_14813194.1216185348986-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6G5Tc0u019040 for ; Wed, 16 Jul 2008 01:29:38 -0400 Received: from mail4.hitachi.co.jp (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6G5TamS015177 for ; Wed, 16 Jul 2008 05:29:37 GMT Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id C067B33CC9 for ; Wed, 16 Jul 2008 14:29:17 +0900 (JST) Date: Wed, 16 Jul 2008 14:29:16 +0900 From: Yuichi Nakamura To: "Willis Vandevanter" Subject: Re: OpenMoko/JFFS2 sestatus difficulties Cc: ynakam@hitachisoft.jp, selinux@tycho.nsa.gov, "KaiGai Kohei" In-Reply-To: <4c63b15c0807152215p271dc8e6m1854ab006245b35@mail.gmail.com> References: <487D46B5.9070608@ak.jp.nec.com> <4c63b15c0807152215p271dc8e6m1854ab006245b35@mail.gmail.com> Message-Id: <20080716141941.E446.F42EC909@hitachisoft.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Hi. On Wed, 16 Jul 2008 01:15:48 -0400 "Willis Vandevanter" wrote: > KaiGai said: > > > I guess selinuxfs is not mounted. > > > I unmounted and remounted /selinux after I copied the new libselinux.so.1 > onto the device. sestatus still returns disabled. Does policy loaded ? If not, sestatus will return SELinux is disabled. You have to mount /selinux then load_policy. BusyBox's /sbin/init does both when SELinux option is enabled. > > I also have the following in /etc/fstab: > > > selinux /selinux selinuxfs noauto 0 0 > > > KaiGai said: > > > If your /sbin/init is implemented using busybox, consider to turn on > > "SELinux support" option > > > > /sbin/init is implemented using busybox, but I'm not sure if the SELinux > support option is turned on. I will have to check on this in the morning. > > Russell said: > > > What exactly is the output of "sestatus"? > > > The output of sestatus is: > > > SELinux status: disabled > > > Justin said: > > > do a ldd /sbin/init, you should see libsepol, and libselinux if not install > > sysvinit > > > > The output from ldd /sbin/init is: > > > libc.so.6 => /lib/libc.so.6 (0x40025000) > > /lib/ld-linux.so.3 (0x40000000) > > > > Oddly enough this is also the output when sestatus reports SELinux as > enabled. sysvinit is installed. > > in grub.conf put selinux=1 enforcing=1/0 <~~~1=on 0=off > > > > I rebooted with the boot parameters appended, but still sestatus reports > SELinux as disabled. Even stranger is dmesg has the following: > > .... > > Security Framework initialized > > SELinux: Initializing. > > SELinux: Starting in permissive mode > > ....... > > SELinux: Registering netfilter hooks > > io scheduler noop registered > > io scheduler deadline registered (default) > > ...... > > > > > It is late here right now =)). I will try the strace on sestatus tomorrow > morning. > > -Willis > > On Tue, Jul 15, 2008 at 8:54 PM, KaiGai Kohei wrote: > > > Willis, > > > > I guess selinuxfs is not mounted. > > > > In SELinux environment, /sbin/init is extended to mount selinuxfs > > on /selinux. It enables to communicate between kernel and userspaces. > > > > If your /sbin/init is implemented using busybox, consider to turn on > > "SELinux support" option and make /selinux directory on your jffs2 image. > > > > > > 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, > >> > > > > Is it your host environment, isn't it? > > > > 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). > >> 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? > >> > >> I apologize for the long email. The policy I am using is available at > >> http://code.google.com/p/selinux-openmoko/. The cross-compiled > >> binaries are also available. I am using a 2.6.24.7 > >> kernel with SELinux > >> and JFFS2 XATTR enabled. > >> > >> Thank you for your help, > >> Willis > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.6 (GNU/Linux) > >> > >> iD8DBQFIfSH2qCokMvr1WNARAuJdAJ0Q9iWp7+V0jTxen92WfE8RFnpJeACgiRyX > >> vAFzngclbVPHIZ/YckQi3Sg= > >> =P7dW > >> -----END PGP SIGNATURE----- > >> > > > > -- > > OSS Platform Development Division, NEC > > KaiGai Kohei > > > > -- > > This message was distributed to subscribers of the selinux mailing list. > > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith > > the words "unsubscribe selinux" without quotes as the message. > > -- Yuichi Nakamura Hitachi Software Engineering Co., Ltd. Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/ SELinux Policy Editor: http://seedit.sourceforge.net/ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6G7EnZc000886 for ; Wed, 16 Jul 2008 03:14:49 -0400 Received: from nospam.sws.net.au (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6G7EgmS008765 for ; Wed, 16 Jul 2008 07:14:43 GMT From: Russell Coker Reply-To: russell@coker.com.au To: "Justin Mattock" Subject: Re: OpenMoko/JFFS2 sestatus difficulties Date: Wed, 16 Jul 2008 17:14:31 +1000 Cc: "KaiGai Kohei" , "Willis Vandevanter" , selinux@tycho.nsa.gov, ynakam@hitachisoft.jp References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <487D46B5.9070608@ak.jp.nec.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200807161714.35195.russell@coker.com.au> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wednesday 16 July 2008 13:13, "Justin Mattock" wrote: > make sure fstab has it entry to mount SELinux, and do a ldd /sbin/init I think that in most situations any requirement for a SE Linux entry in /etc/fstab would be a bug. NB I am not saying that no-one needs it, merely that if you need it then you probably need to fix something else. -- russell@coker.com.au http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6G7lttI005375 for ; Wed, 16 Jul 2008 03:47:55 -0400 Received: from an-out-0708.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6G7lsmS015955 for ; Wed, 16 Jul 2008 07:47:54 GMT Received: by an-out-0708.google.com with SMTP id d30so46799and.75 for ; Wed, 16 Jul 2008 00:47:54 -0700 (PDT) Message-ID: Date: Wed, 16 Jul 2008 07:47:54 +0000 From: "Justin Mattock" To: russell@coker.com.au Subject: Re: OpenMoko/JFFS2 sestatus difficulties Cc: "KaiGai Kohei" , "Willis Vandevanter" , selinux@tycho.nsa.gov, ynakam@hitachisoft.jp In-Reply-To: <200807161714.35195.russell@coker.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <487D46B5.9070608@ak.jp.nec.com> <200807161714.35195.russell@coker.com.au> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, Jul 16, 2008 at 7:14 AM, Russell Coker wrote: > On Wednesday 16 July 2008 13:13, "Justin Mattock" > wrote: >> make sure fstab has it entry to mount SELinux, and do a ldd /sbin/init > > I think that in most situations any requirement for a SE Linux entry > in /etc/fstab would be a bug. NB I am not saying that no-one needs it, > merely that if you need it then you probably need to fix something else. > > -- > russell@coker.com.au > http://etbe.coker.com.au/ My Blog > > http://www.coker.com.au/sponsorship.html Sponsoring Free Software development > I always for some reason put that in fstab just as a good practice, from what I remember like what you had said "you probably need to fix something else". maybe libselinux(older versions) was causing this. Also adding libselinux in /etc/ld.so.conf was another step I used to make sure I did as well. 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: OpenMoko/JFFS2 sestatus difficulties From: Stephen Smalley To: Willis Vandevanter Cc: selinux@tycho.nsa.gov In-Reply-To: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> Content-Type: text/plain Date: Wed, 16 Jul 2008 07:56:15 -0400 Message-Id: <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6GBv0Rp015116 for ; Wed, 16 Jul 2008 07:57:00 -0400 Received: from nospam.sws.net.au (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6GBuwWL023312 for ; Wed, 16 Jul 2008 11:56:59 GMT From: Russell Coker Reply-To: russell@coker.com.au To: "Justin Mattock" Subject: Re: OpenMoko/JFFS2 sestatus difficulties Date: Wed, 16 Jul 2008 21:56:49 +1000 Cc: selinux@tycho.nsa.gov References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <200807161714.35195.russell@coker.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200807162156.53554.russell@coker.com.au> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wednesday 16 July 2008 17:47, "Justin Mattock" wrote: > I always for some reason put that in fstab just as a good practice, > from what I remember like what you had said "you probably need to fix > something else". Some years ago that probably was a good idea (I probably recommended it in the past). However now we have /proc, /dev, /dev/pts, /dev/.static/dev (on Debian and derivatives), /dev/shm, and /sys as well. While there is generally no real performance requirement for making /etc/fstab small and anything less than 4K won't make a difference to the amount of free space on most systems, I think it's best to avoid clutter (it helps when reading such a file while doing late-night support). -- russell@coker.com.au http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6GF3HKx018548 for ; Wed, 16 Jul 2008 11:03:17 -0400 Received: from wx-out-0506.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6GF3Gif015744 for ; Wed, 16 Jul 2008 15:03:16 GMT Received: by wx-out-0506.google.com with SMTP id i26so2702595wxd.30 for ; Wed, 16 Jul 2008 08:03:16 -0700 (PDT) Message-ID: Date: Wed, 16 Jul 2008 15:03:16 +0000 From: "Justin Mattock" To: "Stephen Smalley" Subject: Re: OpenMoko/JFFS2 sestatus difficulties Cc: "Willis Vandevanter" , selinux@tycho.nsa.gov In-Reply-To: <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley 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 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@tycho.nsa.gov 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; -- 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: OpenMoko/JFFS2 sestatus difficulties From: Stephen Smalley To: Justin Mattock Cc: Willis Vandevanter , selinux@tycho.nsa.gov In-Reply-To: References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain Date: Wed, 16 Jul 2008 11:18:12 -0400 Message-Id: <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote: > On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley 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 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@tycho.nsa.gov 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6GGmYGM015622 for ; Wed, 16 Jul 2008 12:48:34 -0400 Received: from an-out-0708.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6GGmThc022575 for ; Wed, 16 Jul 2008 16:48:29 GMT Received: by an-out-0708.google.com with SMTP id d30so78920and.75 for ; Wed, 16 Jul 2008 09:48:29 -0700 (PDT) Message-ID: Date: Wed, 16 Jul 2008 16:48:28 +0000 From: "Justin Mattock" To: "Stephen Smalley" Subject: Re: OpenMoko/JFFS2 sestatus difficulties Cc: "Willis Vandevanter" , selinux@tycho.nsa.gov In-Reply-To: <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, Jul 16, 2008 at 3:18 PM, Stephen Smalley wrote: > > On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote: >> On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley 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 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@tycho.nsa.gov 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: OpenMoko/JFFS2 sestatus difficulties From: Stephen Smalley To: Justin Mattock Cc: Willis Vandevanter , selinux@tycho.nsa.gov In-Reply-To: References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain Date: Wed, 16 Jul 2008 12:56:53 -0400 Message-Id: <1216227413.17602.149.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, 2008-07-16 at 16:48 +0000, Justin Mattock wrote: > On Wed, Jul 16, 2008 at 3:18 PM, Stephen Smalley wrote: > > > > On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote: > >> On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley 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 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@tycho.nsa.gov 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6GILXcC005504 for ; Wed, 16 Jul 2008 14:21:33 -0400 Received: from wx-out-0506.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6GILWhc022293 for ; Wed, 16 Jul 2008 18:21:32 GMT Received: by wx-out-0506.google.com with SMTP id i26so2753742wxd.30 for ; Wed, 16 Jul 2008 11:21:32 -0700 (PDT) Message-ID: Date: Wed, 16 Jul 2008 18:21:31 +0000 From: "Justin Mattock" To: "Stephen Smalley" Subject: Re: OpenMoko/JFFS2 sestatus difficulties Cc: "Willis Vandevanter" , selinux@tycho.nsa.gov In-Reply-To: <1216227413.17602.149.camel@moss-spartans.epoch.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> <1216227413.17602.149.camel@moss-spartans.epoch.ncsc.mil> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, Jul 16, 2008 at 4:56 PM, Stephen Smalley wrote: > > On Wed, 2008-07-16 at 16:48 +0000, Justin Mattock wrote: >> On Wed, Jul 16, 2008 at 3:18 PM, Stephen Smalley wrote: >> > >> > On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote: >> >> On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley 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 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@tycho.nsa.gov 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Attaching multiple user accounts to same home directory... Date: Thu, 17 Jul 2008 12:42:29 -0400 Message-ID: In-Reply-To: <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> From: "Hasan Rezaul-CHR010" To: "Stephen Smalley" Cc: Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Hi All, Suppose I wanted to have several Linux User Accounts tied to the same Home Directory, by executing the following: useradd -g wadm -d /home/admin admin1 useradd -g wadm -d /home/admin admin2 And I wanted all these Linux Users to be tied to the same SELinux user (staff_u) as follows: semanage login -a -s staff_u admin1 semanage login -a -s staff_u admin2 Does SELinux allow this per design ??? Currently I am getting the following errors on my console, which somewhat makes sense, considering this is NOT standard practise! /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/.+. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/.*/plugins/nprhapengine\.so.*. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/.*/plugins/libflashplayer\.so.*. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.ssh(/.*)?. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.xauth.*. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.gnupg(/.+)?. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.fonts(/.*)?. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.gconf(d)?(/.*)?. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.Xauthority.*. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.fonts/auto(/.*)?. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.config/gtk-.*. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.fonts\.cache-.*. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.ICEauthority.*. Inserting powerspanii.ko: /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin. /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /home/admin/\.fonts\.conf. I was wondering if there is any way I can tweak SELinux config or policy to allow multiple Linux users to share the same home directory...without generating all these complaints ? Thanks in advance for your help :-) - Rezaul. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <487F9610.6010104@redhat.com> Date: Thu, 17 Jul 2008 14:57:20 -0400 From: Daniel J Walsh MIME-Version: 1.0 To: Hasan Rezaul-CHR010 CC: Stephen Smalley , selinux@tycho.nsa.gov Subject: Re: Attaching multiple user accounts to same home directory... References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hasan Rezaul-CHR010 wrote: > Hi All, > > Suppose I wanted to have several Linux User Accounts tied to the same > Home Directory, by executing the following: > > useradd -g wadm -d /home/admin admin1 > useradd -g wadm -d /home/admin admin2 > > And I wanted all these Linux Users to be tied to the same SELinux user > (staff_u) as follows: > > semanage login -a -s staff_u admin1 > semanage login -a -s staff_u admin2 > > Does SELinux allow this per design ??? > > Currently I am getting the following errors on my console, which > somewhat makes sense, considering this is NOT standard practise! > > > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/.+. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/.*/plugins/nprhapengine\.so.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/.*/plugins/libflashplayer\.so.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.ssh(/.*)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.xauth.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.gnupg(/.+)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.fonts(/.*)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.gconf(d)?(/.*)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for > /home/admin/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.Xauthority.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.fonts/auto(/.*)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.config/gtk-.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.fonts\.cache-.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.ICEauthority.*. > Inserting powerspanii.ko: > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.fonts\.conf. > > > I was wondering if there is any way I can tweak SELinux config or policy > to allow multiple Linux users to share the same home > directory...without generating all these complaints ? Thanks in advance > for your help :-) > > - Rezaul. > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. I think you have confused the tool. What OS are you doing this on? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh/lhAACgkQrlYvE4MpobNVggCeMLFXrNd5m+I9HEYn8qGJifgD +GEAn3jcHDwH2RSQx3NDNgiFYqz8+xev =4Jln -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Attaching multiple user accounts to same home directory... Date: Thu, 17 Jul 2008 15:20:46 -0400 Message-ID: In-Reply-To: <487F9610.6010104@redhat.com> References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> <487F9610.6010104@redhat.com> From: "Hasan Rezaul-CHR010" To: "Daniel J Walsh" Cc: "Stephen Smalley" , Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Hi Dan, I am using Standard Linux 2.6.14. In case you need this info, the SELinux related packages I am using are: checkpolicy 1.34.1 libselinux 1.34.7 libsemanage 1.10.3 libsepol 1.16.1 policycoreutils 1.34.6 - Rezaul. -----Original Message----- From: Daniel J Walsh [mailto:dwalsh@redhat.com] Sent: Thursday, July 17, 2008 1:57 PM To: Hasan Rezaul-CHR010 Cc: Stephen Smalley; selinux@tycho.nsa.gov Subject: Re: Attaching multiple user accounts to same home directory... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hasan Rezaul-CHR010 wrote: > Hi All, > > Suppose I wanted to have several Linux User Accounts tied to the same > Home Directory, by executing the following: > > useradd -g wadm -d /home/admin admin1 > useradd -g wadm -d /home/admin admin2 > > And I wanted all these Linux Users to be tied to the same SELinux user > (staff_u) as follows: > > semanage login -a -s staff_u admin1 > semanage login -a -s staff_u admin2 > > Does SELinux allow this per design ??? > > Currently I am getting the following errors on my console, which > somewhat makes sense, considering this is NOT standard practise! > > > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/.+. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/.*/plugins/nprhapengine\.so.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/.*/plugins/libflashplayer\.so.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.ssh(/.*)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.xauth.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.gnupg(/.+)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.fonts(/.*)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.gconf(d)?(/.*)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for > /home/admin/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.Xauthority.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.fonts/auto(/.*)?. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.config/gtk-.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.fonts\.cache-.*. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.ICEauthority.*. > Inserting powerspanii.ko: > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin. > /etc/selinux/strict/contexts/files/file_contexts: Multiple same > specifications for /home/admin/\.fonts\.conf. > > > I was wondering if there is any way I can tweak SELinux config or > policy to allow multiple Linux users to share the same home > directory...without generating all these complaints ? Thanks in > advance for your help :-) > > - Rezaul. > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. I think you have confused the tool. What OS are you doing this on? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh/lhAACgkQrlYvE4MpobNVggCeMLFXrNd5m+I9HEYn8qGJifgD +GEAn3jcHDwH2RSQx3NDNgiFYqz8+xev =4Jln -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <487FA2EB.8030608@redhat.com> Date: Thu, 17 Jul 2008 15:52:11 -0400 From: Daniel J Walsh MIME-Version: 1.0 To: Hasan Rezaul-CHR010 CC: Stephen Smalley , selinux@tycho.nsa.gov Subject: Re: Attaching multiple user accounts to same home directory... References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> <487F9610.6010104@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hasan Rezaul-CHR010 wrote: > Hi Dan, > > I am using Standard Linux 2.6.14. > > In case you need this info, the SELinux related packages I am using are: > > checkpolicy 1.34.1 > libselinux 1.34.7 > libsemanage 1.10.3 > libsepol 1.16.1 > policycoreutils 1.34.6 > > - Rezaul. > Can you upgrade to the newer toolchain? I tried to do what you are doing in rawhide and it works fine. rpm -q libselinux checkpolicy libsemanage policycoreutils libsepol libselinux-2.0.67-4.fc10.x86_64 libselinux-2.0.67-4.fc10.i386 checkpolicy-2.0.16-3.fc10.x86_64 libsemanage-2.0.25-3.fc10.x86_64 policycoreutils-2.0.52-5.fc10.x86_64 libsepol-2.0.32-1.fc10.x86_64 > > -----Original Message----- > From: Daniel J Walsh [mailto:dwalsh@redhat.com] > Sent: Thursday, July 17, 2008 1:57 PM > To: Hasan Rezaul-CHR010 > Cc: Stephen Smalley; selinux@tycho.nsa.gov > Subject: Re: Attaching multiple user accounts to same home directory... > > Hasan Rezaul-CHR010 wrote: >> Hi All, > >> Suppose I wanted to have several Linux User Accounts tied to the same >> Home Directory, by executing the following: > >> useradd -g wadm -d /home/admin admin1 >> useradd -g wadm -d /home/admin admin2 > >> And I wanted all these Linux Users to be tied to the same SELinux user >> (staff_u) as follows: > >> semanage login -a -s staff_u admin1 >> semanage login -a -s staff_u admin2 > >> Does SELinux allow this per design ??? > >> Currently I am getting the following errors on my console, which >> somewhat makes sense, considering this is NOT standard practise! > > >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/.+. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/.*/plugins/nprhapengine\.so.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/.*/plugins/libflashplayer\.so.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.ssh(/.*)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.xauth.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.gnupg(/.+)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.fonts(/.*)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.gconf(d)?(/.*)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for >> /home/admin/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.Xauthority.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.fonts/auto(/.*)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.config/gtk-.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.fonts\.cache-.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.ICEauthority.*. >> Inserting powerspanii.ko: >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.fonts\.conf. > > >> I was wondering if there is any way I can tweak SELinux config or >> policy to allow multiple Linux users to share the same home >> directory...without generating all these complaints ? Thanks in >> advance for your help :-) > >> - Rezaul. > > >> -- >> This message was distributed to subscribers of the selinux mailing > list. >> If you no longer wish to subscribe, send mail to >> majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without > quotes as the message. > I think you have confused the tool. What OS are you doing this on? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh/ousACgkQrlYvE4MpobMg+wCgnNCVoe1PRea8MUrWctJBLdVA F4QAmgP5fROkXJWdwaVjAShJQ8zc9Kxi =zUi/ -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <487FA95A.4090601@redhat.com> Date: Thu, 17 Jul 2008 16:19:38 -0400 From: Daniel J Walsh MIME-Version: 1.0 To: Hasan Rezaul-CHR010 CC: Stephen Smalley , selinux@tycho.nsa.gov Subject: Re: Attaching multiple user accounts to same home directory... References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> <487F9610.6010104@redhat.com> <487FA2EB.8030608@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hasan Rezaul-CHR010 wrote: > Hi Dan, > > Given the project deadline and other constraints, upgrading to the new > toolchain is NOT an option for me :-( > > Is there anything else at all I can do as far as tweaking policy or > config to get by this problem ? Thanks for your help... > > - Rezaul. > > No the problem is genhomedircon must be getting confused. You can look at the python code and see if you can figure it out. It must be writing two sets of contexts for the same homedir. > -----Original Message----- > From: Daniel J Walsh [mailto:dwalsh@redhat.com] > Sent: Thursday, July 17, 2008 2:52 PM > To: Hasan Rezaul-CHR010 > Cc: Stephen Smalley; selinux@tycho.nsa.gov > Subject: Re: Attaching multiple user accounts to same home directory... > > Hasan Rezaul-CHR010 wrote: >> Hi Dan, > >> I am using Standard Linux 2.6.14. > >> In case you need this info, the SELinux related packages I am using > are: >> checkpolicy 1.34.1 >> libselinux 1.34.7 >> libsemanage 1.10.3 >> libsepol 1.16.1 >> policycoreutils 1.34.6 > >> - Rezaul. > > > Can you upgrade to the newer toolchain? > > I tried to do what you are doing in rawhide and it works fine. > > rpm -q libselinux checkpolicy libsemanage policycoreutils libsepol > libselinux-2.0.67-4.fc10.x86_64 > libselinux-2.0.67-4.fc10.i386 > checkpolicy-2.0.16-3.fc10.x86_64 > libsemanage-2.0.25-3.fc10.x86_64 > policycoreutils-2.0.52-5.fc10.x86_64 > libsepol-2.0.32-1.fc10.x86_64 > > >> -----Original Message----- >> From: Daniel J Walsh [mailto:dwalsh@redhat.com] >> Sent: Thursday, July 17, 2008 1:57 PM >> To: Hasan Rezaul-CHR010 >> Cc: Stephen Smalley; selinux@tycho.nsa.gov >> Subject: Re: Attaching multiple user accounts to same home > directory... >> Hasan Rezaul-CHR010 wrote: >>> Hi All, >>> Suppose I wanted to have several Linux User Accounts tied to the same > >>> Home Directory, by executing the following: >>> useradd -g wadm -d /home/admin admin1 useradd -g wadm -d /home/admin >>> admin2 >>> And I wanted all these Linux Users to be tied to the same SELinux >>> user >>> (staff_u) as follows: >>> semanage login -a -s staff_u admin1 >>> semanage login -a -s staff_u admin2 >>> Does SELinux allow this per design ??? >>> Currently I am getting the following errors on my console, which >>> somewhat makes sense, considering this is NOT standard practise! > >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/.+. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/.*/plugins/nprhapengine\.so.*. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/.*/plugins/libflashplayer\.so.*. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.ssh(/.*)?. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.xauth.*. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.gnupg(/.+)?. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.fonts(/.*)?. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.gconf(d)?(/.*)?. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for >>> /home/admin/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.Xauthority.*. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.fonts/auto(/.*)?. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.config/gtk-.*. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.fonts\.cache-.*. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.ICEauthority.*. >>> Inserting powerspanii.ko: >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin. >>> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >>> specifications for /home/admin/\.fonts\.conf. > >>> I was wondering if there is any way I can tweak SELinux config or >>> policy to allow multiple Linux users to share the same home >>> directory...without generating all these complaints ? Thanks in >>> advance for your help :-) >>> - Rezaul. > >>> -- >>> This message was distributed to subscribers of the selinux mailing >> list. >>> If you no longer wish to subscribe, send mail to >>> majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without >> quotes as the message. >> I think you have confused the tool. What OS are you doing this on? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh/qVkACgkQrlYvE4MpobOAHQCcCuluoLZc8d+eYS4M2LndV2W3 j/IAoMjWPXHxiVXIc2sh8Uj66tn2SGBY =tfCb -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6HKRR7a031776 for ; Thu, 17 Jul 2008 16:27:27 -0400 Received: from moss-lions.epoch.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6HKRQDU027713 for ; Thu, 17 Jul 2008 20:27:26 GMT Received: from moss-lions.epoch.ncsc.mil (localhost.localdomain [127.0.0.1]) by moss-lions.epoch.ncsc.mil (8.14.1/8.14.1) with ESMTP id m6HKSU49024161 for ; Thu, 17 Jul 2008 16:28:30 -0400 Received: (from jwcart2@localhost) by moss-lions.epoch.ncsc.mil (8.14.1/8.14.1/Submit) id m6HKSUht024160 for selinux@tycho.nsa.gov; Thu, 17 Jul 2008 16:28:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Attaching multiple user accounts to same home directory... Date: Thu, 17 Jul 2008 16:01:00 -0400 Message-ID: In-Reply-To: <487FA2EB.8030608@redhat.com> References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> <487F9610.6010104@redhat.com> <487FA2EB.8030608@redhat.com> From: "Hasan Rezaul-CHR010" To: "Daniel J Walsh" Cc: "Stephen Smalley" , Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Hi Dan, Given the project deadline and other constraints, upgrading to the new toolchain is NOT an option for me :-( Is there anything else at all I can do as far as tweaking policy or config to get by this problem ? Thanks for your help... - Rezaul. -----Original Message----- From: Daniel J Walsh [mailto:dwalsh@redhat.com] Sent: Thursday, July 17, 2008 2:52 PM To: Hasan Rezaul-CHR010 Cc: Stephen Smalley; selinux@tycho.nsa.gov Subject: Re: Attaching multiple user accounts to same home directory... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hasan Rezaul-CHR010 wrote: > Hi Dan, > > I am using Standard Linux 2.6.14. > > In case you need this info, the SELinux related packages I am using are: > > checkpolicy 1.34.1 > libselinux 1.34.7 > libsemanage 1.10.3 > libsepol 1.16.1 > policycoreutils 1.34.6 > > - Rezaul. > Can you upgrade to the newer toolchain? I tried to do what you are doing in rawhide and it works fine. rpm -q libselinux checkpolicy libsemanage policycoreutils libsepol libselinux-2.0.67-4.fc10.x86_64 libselinux-2.0.67-4.fc10.i386 checkpolicy-2.0.16-3.fc10.x86_64 libsemanage-2.0.25-3.fc10.x86_64 policycoreutils-2.0.52-5.fc10.x86_64 libsepol-2.0.32-1.fc10.x86_64 > > -----Original Message----- > From: Daniel J Walsh [mailto:dwalsh@redhat.com] > Sent: Thursday, July 17, 2008 1:57 PM > To: Hasan Rezaul-CHR010 > Cc: Stephen Smalley; selinux@tycho.nsa.gov > Subject: Re: Attaching multiple user accounts to same home directory... > > Hasan Rezaul-CHR010 wrote: >> Hi All, > >> Suppose I wanted to have several Linux User Accounts tied to the same >> Home Directory, by executing the following: > >> useradd -g wadm -d /home/admin admin1 useradd -g wadm -d /home/admin >> admin2 > >> And I wanted all these Linux Users to be tied to the same SELinux >> user >> (staff_u) as follows: > >> semanage login -a -s staff_u admin1 >> semanage login -a -s staff_u admin2 > >> Does SELinux allow this per design ??? > >> Currently I am getting the following errors on my console, which >> somewhat makes sense, considering this is NOT standard practise! > > >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/.+. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/.*/plugins/nprhapengine\.so.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/.*/plugins/libflashplayer\.so.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.ssh(/.*)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.xauth.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.gnupg(/.+)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.fonts(/.*)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.gconf(d)?(/.*)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for >> /home/admin/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.Xauthority.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.fonts/auto(/.*)?. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.config/gtk-.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.fonts\.cache-.*. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.ICEauthority.*. >> Inserting powerspanii.ko: >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin. >> /etc/selinux/strict/contexts/files/file_contexts: Multiple same >> specifications for /home/admin/\.fonts\.conf. > > >> I was wondering if there is any way I can tweak SELinux config or >> policy to allow multiple Linux users to share the same home >> directory...without generating all these complaints ? Thanks in >> advance for your help :-) > >> - Rezaul. > > >> -- >> This message was distributed to subscribers of the selinux mailing > list. >> If you no longer wish to subscribe, send mail to >> majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without > quotes as the message. > I think you have confused the tool. What OS are you doing this on? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh/ousACgkQrlYvE4MpobMg+wCgnNCVoe1PRea8MUrWctJBLdVA F4QAmgP5fROkXJWdwaVjAShJQ8zc9Kxi =zUi/ -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6I0eYwg032370 for ; Thu, 17 Jul 2008 20:40:34 -0400 Received: from arlo.cse.psu.edu (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6I0eVJc016530 for ; Fri, 18 Jul 2008 00:40:34 GMT Subject: Re: OpenMoko/JFFS2 sestatus difficulties From: Mohamed Hassan To: Willis Vandevanter Cc: selinux@tycho.nsa.gov, KaiGai Kohei , ynakam@hitachisoft.jp In-Reply-To: <4c63b15c0807152215p271dc8e6m1854ab006245b35@mail.gmail.com> References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <487D46B5.9070608@ak.jp.nec.com> <4c63b15c0807152215p271dc8e6m1854ab006245b35@mail.gmail.com> Content-Type: text/plain Date: Thu, 17 Jul 2008 20:40:12 -0400 Message-Id: <1216341612.6120.1.camel@cairo> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Hi Willis, We were working on porting SELinux on OopenMoko as part of our research here at Penn State. We successfully got SELinux to work on the phone. You can try enabling extended attributes (xattr) in jffs2. This will require recompiling mtd-utils-native with selinux support (libacl and libattr is required by mtd) Modify bitbake.conf to flash the phone with selinux enabled jffs2 Here is the batch http://www.cse.psu.edu/~mhassan/openmoko_se/bitbake-conf-selinux.patch You can also check our init patch at http://www.cse.psu.edu/~mhassan/openmoko_se/sysvinit-selinux.patch Hope this will help. Thanks, M Hassan On Wed, 2008-07-16 at 01:15 -0400, Willis Vandevanter wrote: > KaiGai said: > I guess selinuxfs is not mounted. > > I unmounted and remounted /selinux after I copied the new > libselinux.so.1 onto the device. sestatus still returns disabled. > > I also have the following in /etc/fstab: > selinux /selinux selinuxfs noauto > 0 0 > > KaiGai said: > If your /sbin/init is implemented using busybox, consider to > turn on > "SELinux support" option > > /sbin/init is implemented using busybox, but I'm not sure if the > SELinux support option is turned on. I will have to check on this in > the morning. > > Russell said: > What exactly is the output of "sestatus"? > > The output of sestatus is: > SELinux status: disabled > > Justin said: > do a ldd /sbin/init, you should see libsepol, and libselinux > if not install sysvinit > > The output from ldd /sbin/init is: > libc.so.6 => /lib/libc.so.6 (0x40025000) > /lib/ld-linux.so.3 (0x40000000) > > Oddly enough this is also the output when sestatus reports SELinux as > enabled. sysvinit is installed. > > in grub.conf put selinux=1 enforcing=1/0 <~~~1=on 0=off > > I rebooted with the boot parameters appended, but still sestatus > reports SELinux as disabled. Even stranger is dmesg has the following: > > > .... > Security Framework initialized > SELinux: Initializing. > SELinux: Starting in permissive mode > ....... > SELinux: Registering netfilter hooks > io scheduler noop registered > io scheduler deadline registered (default) > ...... > > > It is late here right now =)). I will try the strace on sestatus > tomorrow morning. > > > -Willis > > On Tue, Jul 15, 2008 at 8:54 PM, KaiGai Kohei > wrote: > Willis, > > I guess selinuxfs is not mounted. > > In SELinux environment, /sbin/init is extended to mount > selinuxfs > on /selinux. It enables to communicate between kernel and > userspaces. > > If your /sbin/init is implemented using busybox, consider to > turn on > "SELinux support" option and make /selinux directory on your > jffs2 image. > > > 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, > > > Is it your host environment, isn't it? > > 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). > 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? > > I apologize for the long email. The policy I am using > is available at > http://code.google.com/p/selinux-openmoko/. The > cross-compiled > > binaries are also available. I am using a 2.6.24.7 > kernel with SELinux > > and JFFS2 XATTR enabled. > > Thank you for your help, > Willis > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIfSH2qCokMvr1WNARAuJdAJ0Q9iWp7 > +V0jTxen92WfE8RFnpJeACgiRyX > vAFzngclbVPHIZ/YckQi3Sg= > =P7dW > -----END PGP SIGNATURE----- > > > -- > OSS Platform Development Division, NEC > KaiGai Kohei > > -- > This message was distributed to subscribers of the selinux > mailing list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. > > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: RE: Attaching multiple user accounts to same home directory... From: Stephen Smalley To: Hasan Rezaul-CHR010 Cc: Daniel J Walsh , selinux@tycho.nsa.gov In-Reply-To: References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> <487F9610.6010104@redhat.com> <487FA2EB.8030608@redhat.com> Content-Type: text/plain Date: Fri, 18 Jul 2008 08:31:10 -0400 Message-Id: <1216384270.17602.234.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Thu, 2008-07-17 at 16:01 -0400, Hasan Rezaul-CHR010 wrote: > Hi Dan, > > Given the project deadline and other constraints, upgrading to the new > toolchain is NOT an option for me :-( > > Is there anything else at all I can do as far as tweaking policy or > config to get by this problem ? Thanks for your help... These are just warnings and not fatal errors, so you can ignore them. If you want to silence them, then you could always patch libselinux/src/matchpathcon.c to suppress the warning. -- 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Security Context after SSH-ing in... Date: Fri, 30 Apr 2010 16:32:29 -0400 Message-ID: In-Reply-To: References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> <487F9610.6010104@redhat.com> From: "Hasan Rezaul-CHR010" To: "Stephen Smalley" Cc: Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Hi All, I have employed SELinux on our Linux product for a few years now and have written some simple custom policies on top of the base Fedora Core 7 'strict' policy. I am using Standard Linux 2.6.14. And the SELinux related packages I am using are: checkpolicy 1.34.1 libselinux 1.34.7 libsemanage 1.10.3 libsepol 1.16.1 policycoreutils 1.34.6 I have the following user mappings and login mappings defined: root@hapWibbSc2:/var# semanage login -l Login Name SELinux User MLS/MCS Range __default__ user_u s0 admin staff_u s0 root root s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 root@hapWibbSc2:/var# semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 system_r sysadm_r staff_r staff_u staff s0 s0-s0:c0.c1023 sysadm_r staff_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r user_u user s0 s0 user_r Question ======== Most of the time, when I SSH into the system as Linux User "admin", I get a security context of "staff_u:staff_r:staff_t". Which is what I actually want, given how I have configured policy and everything. While the system runs over weeks at customer sites, (don't know exactly what sequence of events transpire on the system, but possibly does include several reboots), SOMETIMES, given the mappings described above, when we SSH in as "admin", we get a security context of: user_u:user_r:user_t ?!? This is obviously NOT desired, and causes my strict policies to complain about things that should have ideally been allowed as staff_t. In these strange situations: I have tried restarting sshd. I have tried rebooting the system. It doesn't seem to correct the problem !! 1. What could be causing this change all of a sudden ? How does this happen given the semanage mappings above ?? 2. What can I do to force the security_context for Linux user "admin" to be reset back to "staff_u:staff_r:staff:t" manually ? 3.What can I do to make sure that the security context remains staff_u:staff_r:staff_t always ! Any other useful pointers or things to check would be appreciated. Thanks as always. R.H. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: Security Context after SSH-ing in... From: Stephen Smalley To: Hasan Rezaul-CHR010 Cc: selinux@tycho.nsa.gov In-Reply-To: References: <4c63b15c0807151517t5c126030q1d80a5c4c4685a4b@mail.gmail.com> <1216209375.17602.77.camel@moss-spartans.epoch.ncsc.mil> <1216221492.17602.131.camel@moss-spartans.epoch.ncsc.mil> <487F9610.6010104@redhat.com> Content-Type: text/plain Date: Mon, 03 May 2010 10:52:06 -0400 Message-Id: <1272898326.20339.45.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Fri, 2010-04-30 at 16:32 -0400, Hasan Rezaul-CHR010 wrote: > Hi All, > > I have employed SELinux on our Linux product for a few years now and > have written some simple custom policies on top of the base Fedora Core > 7 'strict' policy. > > I am using Standard Linux 2.6.14. And the SELinux related packages I am > using are: > > checkpolicy 1.34.1 > libselinux 1.34.7 > libsemanage 1.10.3 > libsepol 1.16.1 > policycoreutils 1.34.6 > > I have the following user mappings and login mappings defined: > > root@hapWibbSc2:/var# semanage login -l > > Login Name SELinux User MLS/MCS Range > > > __default__ user_u s0 > > admin staff_u s0 > > root root s0-s0:c0.c1023 > > system_u system_u s0-s0:c0.c1023 > > > > root@hapWibbSc2:/var# semanage user -l > > Labeling MLS/ MLS/ > SELinux User Prefix MCS Level MCS Range > SELinux Roles > > root sysadm s0 s0-s0:c0.c1023 > system_r sysadm_r staff_r > staff_u staff s0 s0-s0:c0.c1023 > sysadm_r staff_r > sysadm_u sysadm s0 s0-s0:c0.c1023 > sysadm_r > system_u user s0 s0-s0:c0.c1023 > system_r > user_u user s0 s0 > user_r > > > Question > ======== > Most of the time, when I SSH into the system as Linux User "admin", I > get a security context of "staff_u:staff_r:staff_t". Which is what I > actually want, given how I have configured policy and everything. > > While the system runs over weeks at customer sites, (don't know exactly > what sequence of events transpire on the system, but possibly does > include several reboots), SOMETIMES, given the mappings described above, > when we SSH in as "admin", we get a security context of: > > user_u:user_r:user_t ?!? This is obviously NOT desired, and causes my > strict policies to complain about things that should have ideally been > allowed as staff_t. > > In these strange situations: I have tried restarting sshd. I have tried > rebooting the system. It doesn't seem to correct the problem !! > > 1. What could be causing this change all of a sudden ? How does this > happen given the semanage mappings above ?? > 2. What can I do to force the security_context for Linux user "admin" to > be reset back to "staff_u:staff_r:staff:t" manually ? > 3.What can I do to make sure that the security context remains > staff_u:staff_r:staff_t always ! > > Any other useful pointers or things to check would be appreciated. > Thanks as always. - Check that sshd is running in the correct security context (ps -eZ or sestatus -v | grep sshd). - Check that your policy files are labeled correctly (restorecon -Rv /etc/selinux). - Use libselinux/utils/getseuser to check the result, e.g. # ./getseuser admin system_u:system_r:sshd_t:s0 seuser: staff_u, level s0 Context 0 staff_u:staff_r:staff_t:s0 Context 1 staff_u:sysadm_r:sysadm_t:s0 -- 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.