OpenMoko/JFFS2 sestatus difficulties

OpenMoko/JFFS2 sestatus difficulties

[Willis Vandevanter]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

-----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-----

[-- Attachment #2: Type: text/html, Size: 2968 bytes --]

Re: OpenMoko/JFFS2 sestatus difficulties

[KaiGai Kohei]

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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Justin Mattock]

On Wed, Jul 16, 2008 at 12:54 AM, 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.
>

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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Russell Coker]

On Wednesday 16 July 2008 13:13, "Justin Mattock" <justinmattock@gmail.com> 
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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Justin Mattock]

On Wed, Jul 16, 2008 at 7:14 AM, Russell Coker <russell@coker.com.au> wrote:
> On Wednesday 16 July 2008 13:13, "Justin Mattock" <justinmattock@gmail.com>
> 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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Russell Coker]

On Wednesday 16 July 2008 17:47, "Justin Mattock" <justinmattock@gmail.com> 
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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Willis Vandevanter]

[-- Attachment #1: Type: text/plain, Size: 5110 bytes --]

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.govwith
> the words "unsubscribe selinux" without quotes as the message.
>

[-- Attachment #2: Type: text/html, Size: 8164 bytes --]

Re: OpenMoko/JFFS2 sestatus difficulties

[Yuichi Nakamura]

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

Re: OpenMoko/JFFS2 sestatus difficulties

[Mohamed Hassan]

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


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

Re: OpenMoko/JFFS2 sestatus difficulties

[Stephen Smalley]

On Tue, 2008-07-15 at 18:17 -0400, Willis Vandevanter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello All,
> 
>    I am working on developing a targeted SELinux policy for
> OpenMoko devices (www.openmoko.org) as a Google Summer Of Code project
> (http://code.google.com/p/selinux-openmoko/). 
> 
> Background:
> I have cross-compiled the necessary SELinux code (libselinux-1.34.15,
> checkpolicy-1.34.7, libsemanage-1.10.9, libsepol-1.16.14,
> policycoreutils-1.34.16) and devloped a very basic targeted policy. I
> ported the code on to the device. The policy compiles (make) and
> installs (make install).
> 
> Where I am stuck:
> When cross-compiling libselinux I get some strange behavior.
> Specifically, I compiled libselinux with the following flags:
>  make
> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/cc ARCH=arm
> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib 
>  I then copied the new libselinux.so.1 on to the device. sestatus
> returns that SELinux is enabled and lists the correct policy version,
> etc. *BUT* make relabel doesn't work. make relabel (or setfiles) gives
> the following error:
> 
> file_contexts/file_contexts: Invalid argument make: *** [relabel]
> Error 1
> The error seems to be that file_contexts is not being interpreted as a
> regular file (i.e. S_ISREG(sb.st_mode) in setfiles.c is returning 0).

That doesn't seem consistent with the error message; if the S_ISREG()
test fails, setfiles would send the following output to stderr:
	setfiles:  spec file <path> is not a regular file.
So perhaps you are instead encountering an error on the stat() call that
precedes the S_ISREG() test, and the perror() output there is what you
are getting above? 

setfiles is built with -D_FILE_OFFSET_BITS=64 by default, and thus uses
the 64-bit large file system interfaces.  But this can be overridden via
CFLAGS.

> I assume this is because I compiled libselinux without the OpenMoko
> specific header files (ie with my host-x86 /usr/include rather than
> the device specific ones), so I re-compiled libselinux:
> 
> make
> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/ccARCH=arm
> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
> INCLUDEDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include
> I then copied libselinux.so.1 on to the device. setfiles will now
> correctly label the filesystem, but sestatus now returns SELinux as
> disabled. I set /etc/selinux/config file to permissive and rebooted,
> but it is still listed as disabled. 
> 
> How is SELinux determined to be enabled? Could missing or
> mis-configured header files in the OpenMoko /usr/include cause SELinux
> to appear as disabled? 

SELinux enabled vs disabled is determined based on:
- presence/absence of selinuxfs in /proc/filesystems, and
- read of /proc/self/attr/current returns something other than
"kernel" (i.e. policy has been loaded).

-- 
Stephen Smalley
National Security Agency


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

Re: OpenMoko/JFFS2 sestatus difficulties

[Justin Mattock]

On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On Tue, 2008-07-15 at 18:17 -0400, Willis Vandevanter wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello All,
>>
>>    I am working on developing a targeted SELinux policy for
>> OpenMoko devices (www.openmoko.org) as a Google Summer Of Code project
>> (http://code.google.com/p/selinux-openmoko/).
>>
>> Background:
>> I have cross-compiled the necessary SELinux code (libselinux-1.34.15,
>> checkpolicy-1.34.7, libsemanage-1.10.9, libsepol-1.16.14,
>> policycoreutils-1.34.16) and devloped a very basic targeted policy. I
>> ported the code on to the device. The policy compiles (make) and
>> installs (make install).
>>
>> Where I am stuck:
>> When cross-compiling libselinux I get some strange behavior.
>> Specifically, I compiled libselinux with the following flags:
>>  make
>> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/cc ARCH=arm
>> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
>>  I then copied the new libselinux.so.1 on to the device. sestatus
>> returns that SELinux is enabled and lists the correct policy version,
>> etc. *BUT* make relabel doesn't work. make relabel (or setfiles) gives
>> the following error:
>>
>> file_contexts/file_contexts: Invalid argument make: *** [relabel]
>> Error 1
>> The error seems to be that file_contexts is not being interpreted as a
>> regular file (i.e. S_ISREG(sb.st_mode) in setfiles.c is returning 0).
>
> That doesn't seem consistent with the error message; if the S_ISREG()
> test fails, setfiles would send the following output to stderr:
>        setfiles:  spec file <path> is not a regular file.
> So perhaps you are instead encountering an error on the stat() call that
> precedes the S_ISREG() test, and the perror() output there is what you
> are getting above?
>
> setfiles is built with -D_FILE_OFFSET_BITS=64 by default, and thus uses
> the 64-bit large file system interfaces.  But this can be overridden via
> CFLAGS.
>
>> I assume this is because I compiled libselinux without the OpenMoko
>> specific header files (ie with my host-x86 /usr/include rather than
>> the device specific ones), so I re-compiled libselinux:
>>
>> make
>> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/ccARCH=arm
>> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
>> INCLUDEDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include
>> I then copied libselinux.so.1 on to the device. setfiles will now
>> correctly label the filesystem, but sestatus now returns SELinux as
>> disabled. I set /etc/selinux/config file to permissive and rebooted,
>> but it is still listed as disabled.
>>
>> How is SELinux determined to be enabled? Could missing or
>> mis-configured header files in the OpenMoko /usr/include cause SELinux
>> to appear as disabled?
>
> SELinux enabled vs disabled is determined based on:
> - presence/absence of selinuxfs in /proc/filesystems, and
> - read of /proc/self/attr/current returns something other than
> "kernel" (i.e. policy has been loaded).
>
> --
> Stephen Smalley
> National Security Agency
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Stephen Smalley]

On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote:
> On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >
> > On Tue, 2008-07-15 at 18:17 -0400, Willis Vandevanter wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hello All,
> >>
> >>    I am working on developing a targeted SELinux policy for
> >> OpenMoko devices (www.openmoko.org) as a Google Summer Of Code project
> >> (http://code.google.com/p/selinux-openmoko/).
> >>
> >> Background:
> >> I have cross-compiled the necessary SELinux code (libselinux-1.34.15,
> >> checkpolicy-1.34.7, libsemanage-1.10.9, libsepol-1.16.14,
> >> policycoreutils-1.34.16) and devloped a very basic targeted policy. I
> >> ported the code on to the device. The policy compiles (make) and
> >> installs (make install).
> >>
> >> Where I am stuck:
> >> When cross-compiling libselinux I get some strange behavior.
> >> Specifically, I compiled libselinux with the following flags:
> >>  make
> >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/cc ARCH=arm
> >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
> >>  I then copied the new libselinux.so.1 on to the device. sestatus
> >> returns that SELinux is enabled and lists the correct policy version,
> >> etc. *BUT* make relabel doesn't work. make relabel (or setfiles) gives
> >> the following error:
> >>
> >> file_contexts/file_contexts: Invalid argument make: *** [relabel]
> >> Error 1
> >> The error seems to be that file_contexts is not being interpreted as a
> >> regular file (i.e. S_ISREG(sb.st_mode) in setfiles.c is returning 0).
> >
> > That doesn't seem consistent with the error message; if the S_ISREG()
> > test fails, setfiles would send the following output to stderr:
> >        setfiles:  spec file <path> is not a regular file.
> > So perhaps you are instead encountering an error on the stat() call that
> > precedes the S_ISREG() test, and the perror() output there is what you
> > are getting above?
> >
> > setfiles is built with -D_FILE_OFFSET_BITS=64 by default, and thus uses
> > the 64-bit large file system interfaces.  But this can be overridden via
> > CFLAGS.
> >
> >> I assume this is because I compiled libselinux without the OpenMoko
> >> specific header files (ie with my host-x86 /usr/include rather than
> >> the device specific ones), so I re-compiled libselinux:
> >>
> >> make
> >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/ccARCH=arm
> >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
> >> INCLUDEDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include
> >> I then copied libselinux.so.1 on to the device. setfiles will now
> >> correctly label the filesystem, but sestatus now returns SELinux as
> >> disabled. I set /etc/selinux/config file to permissive and rebooted,
> >> but it is still listed as disabled.
> >>
> >> How is SELinux determined to be enabled? Could missing or
> >> mis-configured header files in the OpenMoko /usr/include cause SELinux
> >> to appear as disabled?
> >
> > SELinux enabled vs disabled is determined based on:
> > - presence/absence of selinuxfs in /proc/filesystems, and
> > - read of /proc/self/attr/current returns something other than
> > "kernel" (i.e. policy has been loaded).
> >
> > --
> > Stephen Smalley
> > National Security Agency
> >
> >
> > --
> > This message was distributed to subscribers of the selinux mailing list.
> > If you no longer wish to subscribe, send mail to majordomo@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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Justin Mattock]

On Wed, Jul 16, 2008 at 3:18 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote:
>> On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> >
>> > On Tue, 2008-07-15 at 18:17 -0400, Willis Vandevanter wrote:
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> Hello All,
>> >>
>> >>    I am working on developing a targeted SELinux policy for
>> >> OpenMoko devices (www.openmoko.org) as a Google Summer Of Code project
>> >> (http://code.google.com/p/selinux-openmoko/).
>> >>
>> >> Background:
>> >> I have cross-compiled the necessary SELinux code (libselinux-1.34.15,
>> >> checkpolicy-1.34.7, libsemanage-1.10.9, libsepol-1.16.14,
>> >> policycoreutils-1.34.16) and devloped a very basic targeted policy. I
>> >> ported the code on to the device. The policy compiles (make) and
>> >> installs (make install).
>> >>
>> >> Where I am stuck:
>> >> When cross-compiling libselinux I get some strange behavior.
>> >> Specifically, I compiled libselinux with the following flags:
>> >>  make
>> >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/cc ARCH=arm
>> >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
>> >>  I then copied the new libselinux.so.1 on to the device. sestatus
>> >> returns that SELinux is enabled and lists the correct policy version,
>> >> etc. *BUT* make relabel doesn't work. make relabel (or setfiles) gives
>> >> the following error:
>> >>
>> >> file_contexts/file_contexts: Invalid argument make: *** [relabel]
>> >> Error 1
>> >> The error seems to be that file_contexts is not being interpreted as a
>> >> regular file (i.e. S_ISREG(sb.st_mode) in setfiles.c is returning 0).
>> >
>> > That doesn't seem consistent with the error message; if the S_ISREG()
>> > test fails, setfiles would send the following output to stderr:
>> >        setfiles:  spec file <path> is not a regular file.
>> > So perhaps you are instead encountering an error on the stat() call that
>> > precedes the S_ISREG() test, and the perror() output there is what you
>> > are getting above?
>> >
>> > setfiles is built with -D_FILE_OFFSET_BITS=64 by default, and thus uses
>> > the 64-bit large file system interfaces.  But this can be overridden via
>> > CFLAGS.
>> >
>> >> I assume this is because I compiled libselinux without the OpenMoko
>> >> specific header files (ie with my host-x86 /usr/include rather than
>> >> the device specific ones), so I re-compiled libselinux:
>> >>
>> >> make
>> >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/ccARCH=arm
>> >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
>> >> INCLUDEDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include
>> >> I then copied libselinux.so.1 on to the device. setfiles will now
>> >> correctly label the filesystem, but sestatus now returns SELinux as
>> >> disabled. I set /etc/selinux/config file to permissive and rebooted,
>> >> but it is still listed as disabled.
>> >>
>> >> How is SELinux determined to be enabled? Could missing or
>> >> mis-configured header files in the OpenMoko /usr/include cause SELinux
>> >> to appear as disabled?
>> >
>> > SELinux enabled vs disabled is determined based on:
>> > - presence/absence of selinuxfs in /proc/filesystems, and
>> > - read of /proc/self/attr/current returns something other than
>> > "kernel" (i.e. policy has been loaded).
>> >
>> > --
>> > Stephen Smalley
>> > National Security Agency
>> >
>> >
>> > --
>> > This message was distributed to subscribers of the selinux mailing list.
>> > If you no longer wish to subscribe, send mail to majordomo@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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Stephen Smalley]

On Wed, 2008-07-16 at 16:48 +0000, Justin Mattock wrote:
> On Wed, Jul 16, 2008 at 3:18 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >
> > On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote:
> >> On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >> >
> >> > On Tue, 2008-07-15 at 18:17 -0400, Willis Vandevanter wrote:
> >> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> >> Hash: SHA1
> >> >>
> >> >> Hello All,
> >> >>
> >> >>    I am working on developing a targeted SELinux policy for
> >> >> OpenMoko devices (www.openmoko.org) as a Google Summer Of Code project
> >> >> (http://code.google.com/p/selinux-openmoko/).
> >> >>
> >> >> Background:
> >> >> I have cross-compiled the necessary SELinux code (libselinux-1.34.15,
> >> >> checkpolicy-1.34.7, libsemanage-1.10.9, libsepol-1.16.14,
> >> >> policycoreutils-1.34.16) and devloped a very basic targeted policy. I
> >> >> ported the code on to the device. The policy compiles (make) and
> >> >> installs (make install).
> >> >>
> >> >> Where I am stuck:
> >> >> When cross-compiling libselinux I get some strange behavior.
> >> >> Specifically, I compiled libselinux with the following flags:
> >> >>  make
> >> >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/cc ARCH=arm
> >> >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
> >> >>  I then copied the new libselinux.so.1 on to the device. sestatus
> >> >> returns that SELinux is enabled and lists the correct policy version,
> >> >> etc. *BUT* make relabel doesn't work. make relabel (or setfiles) gives
> >> >> the following error:
> >> >>
> >> >> file_contexts/file_contexts: Invalid argument make: *** [relabel]
> >> >> Error 1
> >> >> The error seems to be that file_contexts is not being interpreted as a
> >> >> regular file (i.e. S_ISREG(sb.st_mode) in setfiles.c is returning 0).
> >> >
> >> > That doesn't seem consistent with the error message; if the S_ISREG()
> >> > test fails, setfiles would send the following output to stderr:
> >> >        setfiles:  spec file <path> is not a regular file.
> >> > So perhaps you are instead encountering an error on the stat() call that
> >> > precedes the S_ISREG() test, and the perror() output there is what you
> >> > are getting above?
> >> >
> >> > setfiles is built with -D_FILE_OFFSET_BITS=64 by default, and thus uses
> >> > the 64-bit large file system interfaces.  But this can be overridden via
> >> > CFLAGS.
> >> >
> >> >> I assume this is because I compiled libselinux without the OpenMoko
> >> >> specific header files (ie with my host-x86 /usr/include rather than
> >> >> the device specific ones), so I re-compiled libselinux:
> >> >>
> >> >> make
> >> >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/ccARCH=arm
> >> >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
> >> >> INCLUDEDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include
> >> >> I then copied libselinux.so.1 on to the device. setfiles will now
> >> >> correctly label the filesystem, but sestatus now returns SELinux as
> >> >> disabled. I set /etc/selinux/config file to permissive and rebooted,
> >> >> but it is still listed as disabled.
> >> >>
> >> >> How is SELinux determined to be enabled? Could missing or
> >> >> mis-configured header files in the OpenMoko /usr/include cause SELinux
> >> >> to appear as disabled?
> >> >
> >> > SELinux enabled vs disabled is determined based on:
> >> > - presence/absence of selinuxfs in /proc/filesystems, and
> >> > - read of /proc/self/attr/current returns something other than
> >> > "kernel" (i.e. policy has been loaded).
> >> >
> >> > --
> >> > Stephen Smalley
> >> > National Security Agency
> >> >
> >> >
> >> > --
> >> > This message was distributed to subscribers of the selinux mailing list.
> >> > If you no longer wish to subscribe, send mail to majordomo@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.

Re: OpenMoko/JFFS2 sestatus difficulties

[Justin Mattock]

On Wed, Jul 16, 2008 at 4:56 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On Wed, 2008-07-16 at 16:48 +0000, Justin Mattock wrote:
>> On Wed, Jul 16, 2008 at 3:18 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> >
>> > On Wed, 2008-07-16 at 15:03 +0000, Justin Mattock wrote:
>> >> On Wed, Jul 16, 2008 at 11:56 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> >> >
>> >> > On Tue, 2008-07-15 at 18:17 -0400, Willis Vandevanter wrote:
>> >> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> >> Hash: SHA1
>> >> >>
>> >> >> Hello All,
>> >> >>
>> >> >>    I am working on developing a targeted SELinux policy for
>> >> >> OpenMoko devices (www.openmoko.org) as a Google Summer Of Code project
>> >> >> (http://code.google.com/p/selinux-openmoko/).
>> >> >>
>> >> >> Background:
>> >> >> I have cross-compiled the necessary SELinux code (libselinux-1.34.15,
>> >> >> checkpolicy-1.34.7, libsemanage-1.10.9, libsepol-1.16.14,
>> >> >> policycoreutils-1.34.16) and devloped a very basic targeted policy. I
>> >> >> ported the code on to the device. The policy compiles (make) and
>> >> >> installs (make install).
>> >> >>
>> >> >> Where I am stuck:
>> >> >> When cross-compiling libselinux I get some strange behavior.
>> >> >> Specifically, I compiled libselinux with the following flags:
>> >> >>  make
>> >> >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/cc ARCH=arm
>> >> >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
>> >> >>  I then copied the new libselinux.so.1 on to the device. sestatus
>> >> >> returns that SELinux is enabled and lists the correct policy version,
>> >> >> etc. *BUT* make relabel doesn't work. make relabel (or setfiles) gives
>> >> >> the following error:
>> >> >>
>> >> >> file_contexts/file_contexts: Invalid argument make: *** [relabel]
>> >> >> Error 1
>> >> >> The error seems to be that file_contexts is not being interpreted as a
>> >> >> regular file (i.e. S_ISREG(sb.st_mode) in setfiles.c is returning 0).
>> >> >
>> >> > That doesn't seem consistent with the error message; if the S_ISREG()
>> >> > test fails, setfiles would send the following output to stderr:
>> >> >        setfiles:  spec file <path> is not a regular file.
>> >> > So perhaps you are instead encountering an error on the stat() call that
>> >> > precedes the S_ISREG() test, and the perror() output there is what you
>> >> > are getting above?
>> >> >
>> >> > setfiles is built with -D_FILE_OFFSET_BITS=64 by default, and thus uses
>> >> > the 64-bit large file system interfaces.  But this can be overridden via
>> >> > CFLAGS.
>> >> >
>> >> >> I assume this is because I compiled libselinux without the OpenMoko
>> >> >> specific header files (ie with my host-x86 /usr/include rather than
>> >> >> the device specific ones), so I re-compiled libselinux:
>> >> >>
>> >> >> make
>> >> >> CC=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/ccARCH=arm
>> >> >> LIBDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib
>> >> >> INCLUDEDIR=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include
>> >> >> I then copied libselinux.so.1 on to the device. setfiles will now
>> >> >> correctly label the filesystem, but sestatus now returns SELinux as
>> >> >> disabled. I set /etc/selinux/config file to permissive and rebooted,
>> >> >> but it is still listed as disabled.
>> >> >>
>> >> >> How is SELinux determined to be enabled? Could missing or
>> >> >> mis-configured header files in the OpenMoko /usr/include cause SELinux
>> >> >> to appear as disabled?
>> >> >
>> >> > SELinux enabled vs disabled is determined based on:
>> >> > - presence/absence of selinuxfs in /proc/filesystems, and
>> >> > - read of /proc/self/attr/current returns something other than
>> >> > "kernel" (i.e. policy has been loaded).
>> >> >
>> >> > --
>> >> > Stephen Smalley
>> >> > National Security Agency
>> >> >
>> >> >
>> >> > --
>> >> > This message was distributed to subscribers of the selinux mailing list.
>> >> > If you no longer wish to subscribe, send mail to majordomo@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.

Attaching multiple user accounts to same home directory...

[Hasan Rezaul-CHR010]

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.

Re: Attaching multiple user accounts to same home directory...

[Daniel J Walsh]

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

RE: Attaching multiple user accounts to same home directory...

[Hasan Rezaul-CHR010]

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.

Re: Attaching multiple user accounts to same home directory...

[Daniel J Walsh]

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

RE: Attaching multiple user accounts to same home directory...

[Hasan Rezaul-CHR010]

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.

Re: Attaching multiple user accounts to same home directory...

[Daniel J Walsh]

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

RE: Attaching multiple user accounts to same home directory...

[Stephen Smalley]

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.

Security Context after SSH-ing in...

[Hasan Rezaul-CHR010]

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.

Re: Security Context after SSH-ing in...

[Stephen Smalley]

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.