ls -Z on non-SE machine

ls -Z on non-SE machine

[Russell Coker]

Currently "ls -Z" refuses to operate if it detects that SE Linux is not 
enabled on the machine.

This makes no sense to me.  Files that are labelled when running SE Linux keep 
their labels (and the values of such labels may still be read) when not 
running SE Linux.  It seems quite reasonable to me that an administrator may 
want to take a disk out of a SE Linux machine and mount it on a non-SE 
machine for debugging problems or forensics.  The current behavior of ls 
works against such operations.

I believe that the best thing to do is to have ls not be linked against 
libselinux and instead just call the XATTR api for reading the file contexts.  
Ideally I think that such functionality should be enabled unconditionally so 
that any administrator who receives a disk that was used on a SE Linux system 
will have the ability to conveniently view all the data on it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: ls -Z on non-SE machine

[Luke Kenneth Casson Leighton]

how about just silently ignoring the -Z option if selinux is
detected to not be enabled?

or placing dummy information in its place which any selinux-aware
shell scripts can pick up on.

On Sun, May 15, 2005 at 07:21:20PM +1000, Russell Coker wrote:
> Currently "ls -Z" refuses to operate if it detects that SE Linux is not 
> enabled on the machine.
> 
> This makes no sense to me.  Files that are labelled when running SE Linux keep 
> their labels (and the values of such labels may still be read) when not 
> running SE Linux.  It seems quite reasonable to me that an administrator may 
> want to take a disk out of a SE Linux machine and mount it on a non-SE 
> machine for debugging problems or forensics.  The current behavior of ls 
> works against such operations.
> 
> I believe that the best thing to do is to have ls not be linked against 
> libselinux and instead just call the XATTR api for reading the file contexts.  
> Ideally I think that such functionality should be enabled unconditionally so 
> that any administrator who receives a disk that was used on a SE Linux system 
> will have the ability to conveniently view all the data on it.
> 
> -- 
> http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> http://www.coker.com.au/~russell/  My home page
> 
> --
> 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.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
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: ls -Z on non-SE machine

[Ivan Gyurdiev]

On Sun, 2005-05-15 at 11:27 +0100, Luke Kenneth Casson Leighton wrote:
> how about just silently ignoring the -Z option if selinux is
> detected to not be enabled?

I believe that's what it does right now, and Russell's arguing against
that behavior - he's saying you should be able to view the contexts,
whether or not SELinux is running (unless I am misunderstanding).

> > I believe that the best thing to do is to have ls not be linked against 
> > libselinux and instead just call the XATTR api for reading the file contexts.  
> > Ideally I think that such functionality should be enabled unconditionally 


-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: ls -Z on non-SE machine

[Russell Coker]

On Sunday 15 May 2005 20:27, Luke Kenneth Casson Leighton <lkcl@lkcl.net> 
wrote:
> how about just silently ignoring the -Z option if selinux is
> detected to not be enabled?
>
> or placing dummy information in its place which any selinux-aware
> shell scripts can pick up on.

You appear to have totally ignored my points about analysis of SE Linux disks 
in non-SE machines and recovery of SE Linux systems from non-SE rescue disks.

We could just not use the -Z option if we don't want the security contexts to 
be displayed.  But the entire point here is to have them available.

> On Sun, May 15, 2005 at 07:21:20PM +1000, Russell Coker wrote:
> > Currently "ls -Z" refuses to operate if it detects that SE Linux is not
> > enabled on the machine.
> >
> > This makes no sense to me.  Files that are labelled when running SE Linux
> > keep their labels (and the values of such labels may still be read) when
> > not running SE Linux.  It seems quite reasonable to me that an
> > administrator may want to take a disk out of a SE Linux machine and mount
> > it on a non-SE machine for debugging problems or forensics.  The current
> > behavior of ls works against such operations.
> >
> > I believe that the best thing to do is to have ls not be linked against
> > libselinux and instead just call the XATTR api for reading the file
> > contexts. Ideally I think that such functionality should be enabled
> > unconditionally so that any administrator who receives a disk that was
> > used on a SE Linux system will have the ability to conveniently view all
> > the data on it.
> >
> > --
> > http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux
> > packages http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> > http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> > http://www.coker.com.au/~russell/  My home page
> >
> > --
> > 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.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: ls -Z on non-SE machine

[Luke Kenneth Casson Leighton]

On Sun, May 15, 2005 at 06:56:59AM -0400, Ivan Gyurdiev wrote:
> On Sun, 2005-05-15 at 11:27 +0100, Luke Kenneth Casson Leighton wrote:
> > how about just silently ignoring the -Z option if selinux is
> > detected to not be enabled?
> 
> I believe that's what it does right now, and Russell's arguing against
> that behavior - he's saying you should be able to view the contexts,
> whether or not SELinux is running (unless I am misunderstanding).
 
 no, it doesn't.  an error is generated saying that the "-Z" argument is
 not understood.

 the resultant error (non-zero exit code) causes, for example,
 initialisation scripts to fail.

 the behaviour is also different: an error code is printed out on
 stderr.

 that's _not_ silent behaviour :)

 yes, i am running my laptop with debian / selinux disabled, with
 the se-aware coreutils package still installed on it.

 every time i boot up, i get a "ls -Z" error in one of the key
 initialisation scripts.

 l.


--
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: ls -Z on non-SE machine

[Luke Kenneth Casson Leighton]

On Sun, May 15, 2005 at 09:11:31PM +1000, Russell Coker wrote:
> On Sunday 15 May 2005 20:27, Luke Kenneth Casson Leighton <lkcl@lkcl.net> 
> wrote:
> > how about just silently ignoring the -Z option if selinux is
> > detected to not be enabled?
> >
> > or placing dummy information in its place which any selinux-aware
> > shell scripts can pick up on.
> 
> You appear to have totally ignored my points about analysis of SE Linux disks 
> in non-SE machines and recovery of SE Linux systems from non-SE rescue disks.
 
 .... ignored, no.
 
 implications-of: hadn't sunk in.

 yep - i get it now.

 l.


--
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: ls -Z on non-SE machine

[Stephen Smalley]

On Sun, 2005-05-15 at 19:21 +1000, Russell Coker wrote:
> Currently "ls -Z" refuses to operate if it detects that SE Linux is not 
> enabled on the machine.

This is a historical artifact of the time when ls --context relied on
the SELinux API, which was only present in SELinux-patched and enabled
kernels (prior to the 2.6 SELinux).  

> This makes no sense to me.  Files that are labelled when running SE Linux keep 
> their labels (and the values of such labels may still be read) when not 
> running SE Linux.  It seems quite reasonable to me that an administrator may 
> want to take a disk out of a SE Linux machine and mount it on a non-SE 
> machine for debugging problems or forensics.  The current behavior of ls 
> works against such operations.

I agree; this is just a historical artifact, although an admin can use
getfattr and similar utilities at present to get this information when
SELinux is disabled.

> I believe that the best thing to do is to have ls not be linked against 
> libselinux and instead just call the XATTR api for reading the file contexts.  
> Ideally I think that such functionality should be enabled unconditionally so 
> that any administrator who receives a disk that was used on a SE Linux system 
> will have the ability to conveniently view all the data on it.

I disagree with this.  ls can be linked against libselinux and use
getfilecon and friends and still work fine on a non-SELinux enabled
system.  If you look at getfilecon's implementation in libselinux,
you'll see that it will work on fine on any kernel that provides the
xattr API and includes the security namespace for xattrs.  Using the
libselinux getfilecon(3) function has the following advantages:
1) It internally handles allocation of the context buffers, simplifying
the application code, unlike getxattr.
2) It encapsulates the attribute name (security.selinux),
3) It allows the introduction of a transparent translation layer within
libselinux to translate MLS labels, as discussed previously (I have some
concerns with this, but it is the current approach by TCS and does save
a lot of engineering time on the individual utilities).

Instead of changing ls to use getxattr, we should just remove the
is_selinux_enabled() check from ls and allow use of -Z at any time
(worst case is that we'll end up with an error return from getfilecon,
which is possible anyway and already being handled for the case where
the filesystem doesn't support xattrs).

-- 
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: ls -Z on non-SE machine

[Russell Coker]

On Monday 16 May 2005 21:31, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > I believe that the best thing to do is to have ls not be linked against
> > libselinux and instead just call the XATTR api for reading the file
> > contexts. Ideally I think that such functionality should be enabled
> > unconditionally so that any administrator who receives a disk that was
> > used on a SE Linux system will have the ability to conveniently view all
> > the data on it.
>
> I disagree with this.  ls can be linked against libselinux and use
> getfilecon and friends and still work fine on a non-SELinux enabled
> system.

It's true that libselinux functionality required by ls can work on a non-SE 
machine.  However in that case when coreutils is compiled for non-SE systems 
ls will not have such functionality.  I believe that it would be best to have 
the "ls -Z" functionality on systems without libselinux.

> If you look at getfilecon's implementation in libselinux, 
> you'll see that it will work on fine on any kernel that provides the
> xattr API and includes the security namespace for xattrs.  Using the
> libselinux getfilecon(3) function has the following advantages:
> 1) It internally handles allocation of the context buffers, simplifying
> the application code, unlike getxattr.

There is already code in coreutils to manage xattrs, can some of that be 
re-used?

> Instead of changing ls to use getxattr, we should just remove the
> is_selinux_enabled() check from ls and allow use of -Z at any time
> (worst case is that we'll end up with an error return from getfilecon,
> which is possible anyway and already being handled for the case where
> the filesystem doesn't support xattrs).

The MLS issue is compelling, this change will do.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: ls -Z on non-SE machine

[Stephen Smalley]

On Mon, 2005-05-16 at 21:48 +1000, Russell Coker wrote:
> It's true that libselinux functionality required by ls can work on a non-SE 
> machine.  However in that case when coreutils is compiled for non-SE systems 
> ls will not have such functionality.  I believe that it would be best to have 
> the "ls -Z" functionality on systems without libselinux.

Not sure that this is a real issue; distros have seemed willing to
accept libselinux as part of the base system, much like libattr/libacl.
If they weren't, then we'd have to revisit the patches anyway to allow
dlopen'ing of libselinux so that they could ship a single coreutils
binary package that could support either SELinux or non-SELinux, as
noted previously by Luke.

> There is already code in coreutils to manage xattrs, can some of that be 
> re-used?

I think that there is code for preserving attributes, and in the case of
ls, code for indicating whether the file has attributes via a simple
flag in the mode string, but I don't think they include code for
displaying attributes in ls - I think they require you to run a separate
utility to display the attributes like getfattr or getfacl.  SELinux is
distinctive in the level of direct integration.  And in the case of
preserving attributes, SELinux tends to do it differently (via
setfscreatecon) so that the attributes are set down when the file is
created rather than later.

> The MLS issue is compelling, this change will do.

Yes, I think just removing the is_selinux_enabled() test is sane in the
case of ls.   Might be more problematic for programs like cp where they
are using SELinux-specific interfaces like setfscreatecon.

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