selinux & external hd permissions.

[Justin Conover]

Currently I have a server with a raid 5 for my wifes photography
backups and some other stuff I keep.  I want to get an exteranl hd
like a LaCie 500GB firewire/usb for backup of that file system for
extra safety.

Question is, if that server is running SELinux on CentOS 4.0 and I
back stuff up to that exteranl drive, will other box's be able to read
that exteranl drive?  In the chance that hardware fails and I need to
be able to look at that data on another box?

Or, would it just be better to format the external with fat32 or
something my wife can use her box to pull the data off?

On Sat, 11 Jun 2005 11:28:20 CDT, Justin Conover said:

>  Question is, if that server is running SELinux on CentOS 4.0 and I
>  back stuff up to that exteranl drive, will other box's be able to read
>  that exteranl drive?  In the chance that hardware fails and I need to
>  be able to look at that data on another box? 
SELinux will enter into it very little.  Just make sure that the drive is using
a file system the other box has support for.  A bigger issue will be "does
the other box have support for your file system?".  Using reiserfs may be
a problem if the other box doesn't have it, and even ext3 will be.. interesting..
if the other box is a Windows box (in which case you're probably better off
just making the FS fat32 and mounting it on your SELinux box with fscontext=)

Please note that if the other box *writes* to the file system, you'll probably
need to run 'restorecon' on it when you mount it back on the SELinux-bsed box
before things will really work right, and you are the mercy of the other box'es
security while it's mounted there.

If you trust the other box to not leave a Trojan on the file system, the quick
answer is "go for it, and restorecon when it comes back".  If you don't
trust
the other box, then it gets a lot more interesting....

[Justin Conover]

On 6/11/05, Valdis.Kletnieks(a)vt.edu <Valdis.Kletnieks(a)vt.edu&gt; wrote:
>  On Sat, 11 Jun 2005 11:28:20 CDT, Justin Conover said:
>  
>  > Question is, if that server is running SELinux on CentOS 4.0 and I
>  > back stuff up to that exteranl drive, will other box's be able to read
>  > that exteranl drive?  In the chance that hardware fails and I need to
>  > be able to look at that data on another box?
>  
>  SELinux will enter into it very little.  Just make sure that the drive is using
>  a file system the other box has support for.  A bigger issue will be "does
>  the other box have support for your file system?".  Using reiserfs may be
>  a problem if the other box doesn't have it, and even ext3 will be.. interesting..
>  if the other box is a Windows box (in which case you're probably better off
>  just making the FS fat32 and mounting it on your SELinux box with fscontext=)
>  
>  Please note that if the other box *writes* to the file system, you'll probably
>  need to run 'restorecon' on it when you mount it back on the SELinux-bsed box
>  before things will really work right, and you are the mercy of the other box'es
>  security while it's mounted there.
>  
>  If you trust the other box to not leave a Trojan on the file system, the quick
>  answer is "go for it, and restorecon when it comes back".  If you don't
> trust
>  the other box, then it gets a lot more interesting....
>   
The Server is CentOS 4.0 with ext3 and SELinux enabled, all my other
box's are Fedora/rawhide using selinux.  My wife has two windows box's
and the only reason I would connect it to her's is if there was some
kind of problem haveing another selinux box read the fs, so thats why
I thought maybe it would be best to just put fat32 on there.  If the
other selinux box's can read it then I wont worry about it.  Also the
only reason I would mv the exteranl drive off my server is if there
was a hardware failure in the server and had to recover the data.

On Sun, 12 Jun 2005 08:12:48 CDT, Justin Conover said:

>  The Server is CentOS 4.0 with ext3 and SELinux enabled, all my other
>  box's are Fedora/rawhide using selinux.  My wife has two windows box's
>  and the only reason I would connect it to her's is if there was some
>  kind of problem haveing another selinux box read the fs, so thats why
>  I thought maybe it would be best to just put fat32 on there.  If the
>  other selinux box's can read it then I wont worry about it.  Also the
>  only reason I would mv the exteranl drive off my server is if there
>  was a hardware failure in the server and had to recover the data. 
The data will be readable off any box that supports ext3 and extended
attributes (I can't remember what happens if the kernel doesn't do the
extended attributes - whether it won't mount, or it mounts-and-ignores).
At worst, you'd need to drop to 'permissive' mode and/or restorecon.

[Justin Conover]

On 6/12/05, Valdis.Kletnieks(a)vt.edu <Valdis.Kletnieks(a)vt.edu&gt; wrote:
>  On Sun, 12 Jun 2005 08:12:48 CDT, Justin Conover said:
>  
>  > The Server is CentOS 4.0 with ext3 and SELinux enabled, all my other
>  > box's are Fedora/rawhide using selinux.  My wife has two windows box's
>  > and the only reason I would connect it to her's is if there was some
>  > kind of problem haveing another selinux box read the fs, so thats why
>  > I thought maybe it would be best to just put fat32 on there.  If the
>  > other selinux box's can read it then I wont worry about it.  Also the
>  > only reason I would mv the exteranl drive off my server is if there
>  > was a hardware failure in the server and had to recover the data.
>  
>  The data will be readable off any box that supports ext3 and extended
>  attributes (I can't remember what happens if the kernel doesn't do the
>  extended attributes - whether it won't mount, or it mounts-and-ignores).
>  At worst, you'd need to drop to 'permissive' mode and/or restorecon. 
True, I didn't think about that :D

[Russell Coker]

On Sunday 12 June 2005 23:23, Valdis.Kletnieks(a)vt.edu wrote:
>  The data will be readable off any box that supports ext3 and
> extended
>  attributes (I can't remember what happens if the kernel doesn't do the
>  extended attributes - whether it won't mount, or it mounts-and-ignores).
>  At worst, you'd need to drop to 'permissive' mode and/or restorecon. 
Code to support XATTRs in Ext2/3 has been there for quite a while.  Code that 
works properly (and base Ext2/3 code that has no bugs related to this) is a 
bit newer.

If you have a file system with XATTRs on sym-links (SE Linux puts XATTRs on 
all file system objects) and then try to mount it on an older 2.4.x kernel 
then there will be problems, I can't remember if the problems merely made the 
file system unusable of whether a full kernel panic occurred.  In any case 
the result was not good.

If you need to share a disk with an old 2.4.x machine then a good solution is 
to mount it with -o context=...  Then the context is stored in kernel memory 
and never written to disk (unless you use a program such as mv or cp that 
does it - but it will not be done automatically by the kernel).

For an external device the context= mount option is good for security too.  
Devices that are mounted nosuid also inhibit domain_auto_trans() rules, but 
having arbitrary data types on files is not desirable.


But generally the answer is that there is no serious issue no matter what you 
want to do.  You just have to do it in the right way.

Also note that some new file system features in recent 2.6.x kernels are not 
supported on 2.4.x.  So you may have some issues with using an old kernel 
even if not using SE Linux.

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

On Sun, 19 Jun 2005 18:00:24 +1000, Russell Coker said:
>  On Sunday 12 June 2005 23:23, Valdis.Kletnieks(a)vt.edu wrote:
>  > The data will be readable off any box that supports ext3 and extended
>  > attributes (I can't remember what happens if the kernel doesn't do the
>  > extended attributes - whether it won't mount, or it mounts-and-ignores).
>  > At worst, you'd need to drop to 'permissive' mode and/or restorecon.
>  
>  Code to support XATTRs in Ext2/3 has been there for quite a while.  Code that
>  works properly (and base Ext2/3 code that has no bugs related to this) is a 
>  bit newer. 
I was thinking more along the lines of somebody who had build themselves a custom
kernel that had CONFIG_EXT[23]_FS_XATTR disabled