Labeled NFS

Labeled NFS

[Myklebust, Trond]

OK, I've pushed out a tentative 'linux-next', and 'testing' branch with
the client side labeled NFS stuff merged.

See the gitweb repository on:

    http://git.linux-nfs.org/?p=trondmy/linux-nfs.git;a=summary


Please test...


-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: labeled NFS

[Stephen Smalley]

On Mon, 2012-05-21 at 15:50 +0400, zyxel wrote:
> Hello.
> I have another question about labeled nfs.
> 
> If both client and server have are patched to support labeled NFS and
> if on the client side policy is set to permissive and on server side
> policy is set to enforcing,
> we can access files on the server from the client without any
> restrictions.
> Is it correct behaviour?

I believe so, as the LNFS implementation only deals with object labeling
support for NFSv4.  Conveying the client process security label to the
server (so that the server can enforce per-process access controls)
would be provided by another mechanism such as RPCSEC_GSSv3.

-- 
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: labeled NFS

[zyxel]

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

Hello.
I have another question about labeled nfs.

If both client and server have are patched to support labeled NFS and if on
the client side policy is set to permissive and on server side policy is
set to enforcing,
we can access files on the server from the client without any restrictions.
Is it correct behaviour?

Andrei

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

Re: labeled NFS

[zyxel]

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

dmesg output are listed here:

Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
Slow work thread pool: Starting up
Slow work thread pool: Ready
FS-Cache: Loaded
FS-Cache: Netfs 'nfs' registered for caching
SELinux: initialized (dev 0:17, type nfs4), uses native labeling
BUG: unable to handle kernel NULL pointer dereference at 0000000000000204
IP: [<ffffffffa03512b8>] nfs4_remote_get_sb+0x148/0x330 [nfs]
PGD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/block/dm-0/dev
CPU 0
Modules linked in: nfs fscache nfsd lockd nfs_acl auth_rpcgss exportfs fuse
autofs4 sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter
ip_tables ip6t_REJECT nf_conntrack_ipv6 xt_state nf_conntrack
ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log uinput
floppy microcode virtio_balloon virtio_net pcspkr snd_hda_intel
snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd
soundcore snd_page_alloc i2c_piix4 i2c_core ext4 mbcache jbd2 virtio_blk
virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mod [last
unloaded: speedstep_lib]
Pid: 2191, comm: mount.nfs4 Not tainted 2.6.32NFS_TEST #1 KVM
RIP: 0010:[<ffffffffa03512b8>]  [<ffffffffa03512b8>]
nfs4_remote_get_sb+0x148/0x330 [nfs]
RSP: 0018:ffff88003bae3c48  EFLAGS: 00010287
RAX: ffff880026a013c0 RBX: ffff88003c635800 RCX: 0000000000000004
RDX: 0000000000000004 RSI: ffff880026a013c0 RDI: ffff880026a2bdb8
RBP: ffff88003bae3cb8 R08: ffff880026a2bde8 R09: ffff880026a013c0
R10: 000000010002214a R11: 0000000000000001 R12: ffff88003ba03480
R13: ffff88003f8701c0 R14: 0000000000000000 R15: ffff88003be0c000
FS:  00007f59127a3700(0000) GS:ffff880001e00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000204 CR3: 000000003ba5f000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mount.nfs4 (pid: 2191, threadinfo ffff88003bae2000, task
ffff880037758aa0)
Stack:
 00000000000000d0 ffff88003b06da80 ffff88003b06da80 ffff880021c55b40
 <0> ffff88003a15cc00 0000000000000000 ffff88003bae3c88 0000000000000000
 <0> ffff88003bae3cb8 ffff88003b06da80 ffffffffa03870a0 0000000000000000
 Call Trace:
  [<ffffffff8115186b>] vfs_kern_mount+0x7b/0x1b0
   [<ffffffffa0350c2f>] nfs_do_root_mount+0x7f/0xb0 [nfs]
    [<ffffffffa0350d72>] nfs4_try_mount+0x52/0xd0 [nfs]
     [<ffffffffa0351652>] nfs4_get_sb+0xa2/0x340 [nfs]
      [<ffffffff8115186b>] vfs_kern_mount+0x7b/0x1b0
       [<ffffffff81151a12>] do_kern_mount+0x52/0x130
        [<ffffffff8116eda7>] do_mount+0x2e7/0x840
         [<ffffffff8116c8f2>] ? copy_mount_options+0xf2/0x1a0
          [<ffffffff8116f390>] sys_mount+0x90/0xe0
           [<ffffffff81013072>] system_call_fastpath+0x16/0x1b
           Code: f7 45 31 f6 e8 0a 2a ff ff 49 83 7f 68 00 0f 84 4a 01 00
00 4c 89 e6 4c 89 ff e8 84 9c ff ff 48 3d 00 f0 ff ff 0f 87 b9 01 00 00
<41> 8b 96 04 02 00 00 4c 8d ab 90 01 00 00 48 8d 4d c8 4c 89 ff
           RIP  [<ffffffffa03512b8>] nfs4_remote_get_sb+0x148/0x330 [nfs]
            RSP <ffff88003bae3c48>
            CR2: 0000000000000204
            ---[ end trace 2ef321f85929034b ]---


I noticed that this error comes out when mounting the same nfs share on
client without nosharecache option, but I can't understand why.
So if I mount
 #mount -t nfs4 -o nosharecache server:/ /mnt/nfsv4
and then
 #mount -t nfs4 -o nosharecache server:/ /mnt/nfsv4_2
everything works fine.

For now I have one more question: could I use netlabel for my task to
prevent access to NFS shared files for processes with lower security level?
I found not enough information about netlabel and how to configure it.
Maybe it may help me. Or it can't be done and I must use labeled NFS
instead.

2012/5/11 Casey Schaufler <casey@schaufler-ca.com>

>  On 5/11/2012 4:05 AM, zyxel wrote:
>
> Hello.
>
> I have some questions about labeled NFS.
> We have client and server systems running RHEL 6.1
> Kernels for both client and server were downloaded from git://
> git.selinuxproject.org/~dpquigl/lnfs<http://git.selinuxproject.org/%7Edpquigl/lnfs>
> Kernel version is 2.6.32. and they are already patched to support labeled
> NFS.
> Server is configured to export NFS share. Nfs-utils on server are patched
> for labeled nfs too.
>
> Here is listing for server exports file:
> /export *(rw,fsid=0,sec=unix,insecure,no_subtree_check,sync,security_label)
>
> Client and server have the same MLS policy.
>
> If I mount NFS share with command
>  #mount -t nfs4 server:/ /mnt/nfsv4
> everything works good, but when i try to mount the same share to another
> directory
>  #mount -t nfs4 server:/ /mnt/nfsv4_2
> it fails with:
>
> Message from syslogd@localhost at May 11 13:07:17 ...
> kernel:Oops: 0000 [#1] SMP
>
> Message from syslogd@localhost at May 11 13:07:17 ...
> kernel:last sysfs file: /sys/devices/virtual/block/dm-0/dev
>
> Message from syslogd@localhost at May 11 13:07:17 ...
> kernel:Stack:
>
>
> An "Oops" indicates that a component of the kernel had a fatal
> error, but that it only affected the current process or device
> and the kernel was able to continue otherwise.
>
> Use dmesg to see the kernel log. Any number of issues, from
> misconfiguration to just plain bad code could have caused your
> problem. There is not enough information in your email to do
> much diagnosis.
>
>
>
> Why does it happens? Where I can get more information about that.
>
> The second question is that maybe I don't need labeled NFS.
> My task is to transfer security levels between client and server over NFS
> so that client with security level s0, for example, couldn't get access to
> file with level s1 on NFS share.
> I don't know if it may be done with netlabel or something.
> Could you help me a bit.
>
> Andrei
>
>
>

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

Re: labeled NFS

[Casey Schaufler]

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

On 5/11/2012 4:05 AM, zyxel wrote:
> Hello.
>
> I have some questions about labeled NFS.
> We have client and server systems running RHEL 6.1
> Kernels for both client and server were downloaded from
> git://git.selinuxproject.org/~dpquigl/lnfs
> <http://git.selinuxproject.org/%7Edpquigl/lnfs>
> Kernel version is 2.6.32. and they are already patched to support
> labeled NFS.
> Server is configured to export NFS share. Nfs-utils on server are
> patched for labeled nfs too.
>
> Here is listing for server exports file:
> /export
> *(rw,fsid=0,sec=unix,insecure,no_subtree_check,sync,security_label)
>
> Client and server have the same MLS policy.
>
> If I mount NFS share with command
>  #mount -t nfs4 server:/ /mnt/nfsv4
> everything works good, but when i try to mount the same share to
> another directory
>  #mount -t nfs4 server:/ /mnt/nfsv4_2
> it fails with:
>
> Message from syslogd@localhost at May 11 13:07:17 ...
> kernel:Oops: 0000 [#1] SMP
>  
> Message from syslogd@localhost at May 11 13:07:17 ...
> kernel:last sysfs file: /sys/devices/virtual/block/dm-0/dev
>  
> Message from syslogd@localhost at May 11 13:07:17 ...
> kernel:Stack:

An "Oops" indicates that a component of the kernel had a fatal
error, but that it only affected the current process or device
and the kernel was able to continue otherwise.

Use dmesg to see the kernel log. Any number of issues, from
misconfiguration to just plain bad code could have caused your
problem. There is not enough information in your email to do
much diagnosis.


>
> Why does it happens? Where I can get more information about that.
>
> The second question is that maybe I don't need labeled NFS.
> My task is to transfer security levels between client and server over NFS
> so that client with security level s0, for example, couldn't get
> access to file with level s1 on NFS share.
> I don't know if it may be done with netlabel or something.
> Could you help me a bit.
>
> Andrei


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

labeled NFS

[zyxel]

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

Hello.

I have some questions about labeled NFS.
We have client and server systems running RHEL 6.1
Kernels for both client and server were downloaded from git://
git.selinuxproject.org/~dpquigl/lnfs
Kernel version is 2.6.32. and they are already patched to support labeled
NFS.
Server is configured to export NFS share. Nfs-utils on server are patched
for labeled nfs too.

Here is listing for server exports file:
/export *(rw,fsid=0,sec=unix,insecure,no_subtree_check,sync,security_label)

Client and server have the same MLS policy.

If I mount NFS share with command
 #mount -t nfs4 server:/ /mnt/nfsv4
everything works good, but when i try to mount the same share to another
directory
 #mount -t nfs4 server:/ /mnt/nfsv4_2
it fails with:

Message from syslogd@localhost at May 11 13:07:17 ...
kernel:Oops: 0000 [#1] SMP

Message from syslogd@localhost at May 11 13:07:17 ...
kernel:last sysfs file: /sys/devices/virtual/block/dm-0/dev

Message from syslogd@localhost at May 11 13:07:17 ...
kernel:Stack:

Why does it happens? Where I can get more information about that.

The second question is that maybe I don't need labeled NFS.
My task is to transfer security levels between client and server over NFS
so that client with security level s0, for example, couldn't get access to
file with level s1 on NFS share.
I don't know if it may be done with netlabel or something.
Could you help me a bit.

Andrei

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