All of lore.kernel.org
 help / color / mirror / Atom feed
* NFSv4.2 unlabeled_t on mountpoints
@ 2016-09-15  7:15 Jason Zaman
  2016-09-15 14:00 ` Dominick Grift
  2016-09-15 14:09 ` Stephen Smalley
  0 siblings, 2 replies; 4+ messages in thread
From: Jason Zaman @ 2016-09-15  7:15 UTC (permalink / raw)
  To: selinux

Hi All,

I have kerberized NFSv4 between my laptop and server and when I use
vers=4.2 I cannot access the mount. It looks like the fcontext needs to
be invalidated or re-checked or something but I'm not familiar with
kernel internals so not sure how to fix it (If someone can point me to
the place, I'd love to get my hands dirty).

Steps to repro:
kinit works fine
mount /home/jason/bregalad works fine, the fstab line is:
bregalad.perfinion.com:/jason /home/jason/bregalad nfs4 noauto,users,vers=4.2,sec=krb5p,rw,intr,soft,timeo=100,_netdev,fsc 0 0

Once mounted as my normal user:
$ ls -aldZ /home/jason/bregalad
ls: cannot access /home/jason/bregalad: Permission denied

I get the following denial:
type=AVC msg=audit(1473923050.591:1577): avc:  denied  { getattr } for  pid=7630 comm="ls" path="/home/jason/bregalad" dev="0:55" ino=4 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
type=SYSCALL msg=audit(1473923050.591:1577): arch=c000003e syscall=6 success=no exit=-13 a0=399b2bc22f2 a1=7a03d6e960 a2=7a03d6e960 a3=7a02aa8d7b items=1 ppid=6440 pid=7630 auid=1000 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=pts3 ses=5 comm="ls" exe="/bin/ls" subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1473923050.591:1577):  cwd="/home/jason"
type=PATH msg=audit(1473923050.591:1577): item=0 name="/home/jason/bregalad" inode=4 dev=00:37 mode=040711 ouid=1000 ogid=100 rdev=00:00 obj=system_u:object_r:unlabeled_t:s0 nametype=NORMAL
type=PROCTITLE msg=audit(1473923050.591:1577): proctitle=6C73002D46002D2D636F6C6F723D6175746F002D616C645A002F686F6D652F6A61736F6E2F62726567616C6164

If I ls with sysadm_t (which has permissions for unlabeled_t) then the
fcontext swaps to what it should be and everything works after that as
staff_t too. I have not had issues with other dirs/files inside the NFS
mount, only the mountpoint has this issue. 

As root / sysadm_t: # ls -aldZ /home/jason/bregalad
drwx--x--x. 50 jason users staff_u:object_r:user_home_dir_t:s0 84 Sep 13 22:38 /home/jason/bregalad/
As jason / staff_t: $ ls -aldZ /home/jason/bregalad
drwx--x--x. 50 jason users staff_u:object_r:user_home_dir_t:s0 84 Sep 13 22:38 /home/jason/bregalad/

$ uname -a
Linux meriadoc 4.7.2-hardened-r1 #1 SMP PREEMPT Sat Sep 3 11:27:29 SGT 2016 x86_64 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz GenuineIntel GNU/Linux
I'm on gentoo hardened but dont think GRSec is responsible here. I also had the same problem back on 4.4.

Is there anything else that can help track this down?
-- Jason

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NFSv4.2 unlabeled_t on mountpoints
  2016-09-15  7:15 NFSv4.2 unlabeled_t on mountpoints Jason Zaman
@ 2016-09-15 14:00 ` Dominick Grift
  2016-09-15 14:09 ` Stephen Smalley
  1 sibling, 0 replies; 4+ messages in thread
From: Dominick Grift @ 2016-09-15 14:00 UTC (permalink / raw)
  To: selinux


[-- Attachment #1.1: Type: text/plain, Size: 3274 bytes --]

Have you looked at this (might be outdated):

http://selinuxproject.org/page/Labeled_NFS

On 09/15/2016 09:15 AM, Jason Zaman wrote:
> Hi All,
> 
> I have kerberized NFSv4 between my laptop and server and when I use
> vers=4.2 I cannot access the mount. It looks like the fcontext needs to
> be invalidated or re-checked or something but I'm not familiar with
> kernel internals so not sure how to fix it (If someone can point me to
> the place, I'd love to get my hands dirty).
> 
> Steps to repro:
> kinit works fine
> mount /home/jason/bregalad works fine, the fstab line is:
> bregalad.perfinion.com:/jason /home/jason/bregalad nfs4 noauto,users,vers=4.2,sec=krb5p,rw,intr,soft,timeo=100,_netdev,fsc 0 0
> 
> Once mounted as my normal user:
> $ ls -aldZ /home/jason/bregalad
> ls: cannot access /home/jason/bregalad: Permission denied
> 
> I get the following denial:
> type=AVC msg=audit(1473923050.591:1577): avc:  denied  { getattr } for  pid=7630 comm="ls" path="/home/jason/bregalad" dev="0:55" ino=4 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
> type=SYSCALL msg=audit(1473923050.591:1577): arch=c000003e syscall=6 success=no exit=-13 a0=399b2bc22f2 a1=7a03d6e960 a2=7a03d6e960 a3=7a02aa8d7b items=1 ppid=6440 pid=7630 auid=1000 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=pts3 ses=5 comm="ls" exe="/bin/ls" subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null)
> type=CWD msg=audit(1473923050.591:1577):  cwd="/home/jason"
> type=PATH msg=audit(1473923050.591:1577): item=0 name="/home/jason/bregalad" inode=4 dev=00:37 mode=040711 ouid=1000 ogid=100 rdev=00:00 obj=system_u:object_r:unlabeled_t:s0 nametype=NORMAL
> type=PROCTITLE msg=audit(1473923050.591:1577): proctitle=6C73002D46002D2D636F6C6F723D6175746F002D616C645A002F686F6D652F6A61736F6E2F62726567616C6164
> 
> If I ls with sysadm_t (which has permissions for unlabeled_t) then the
> fcontext swaps to what it should be and everything works after that as
> staff_t too. I have not had issues with other dirs/files inside the NFS
> mount, only the mountpoint has this issue. 
> 
> As root / sysadm_t: # ls -aldZ /home/jason/bregalad
> drwx--x--x. 50 jason users staff_u:object_r:user_home_dir_t:s0 84 Sep 13 22:38 /home/jason/bregalad/
> As jason / staff_t: $ ls -aldZ /home/jason/bregalad
> drwx--x--x. 50 jason users staff_u:object_r:user_home_dir_t:s0 84 Sep 13 22:38 /home/jason/bregalad/
> 
> $ uname -a
> Linux meriadoc 4.7.2-hardened-r1 #1 SMP PREEMPT Sat Sep 3 11:27:29 SGT 2016 x86_64 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz GenuineIntel GNU/Linux
> I'm on gentoo hardened but dont think GRSec is responsible here. I also had the same problem back on 4.4.
> 
> Is there anything else that can help track this down?
> -- Jason
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 


-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NFSv4.2 unlabeled_t on mountpoints
  2016-09-15  7:15 NFSv4.2 unlabeled_t on mountpoints Jason Zaman
  2016-09-15 14:00 ` Dominick Grift
@ 2016-09-15 14:09 ` Stephen Smalley
  2016-09-15 16:36   ` Dave Quigley
  1 sibling, 1 reply; 4+ messages in thread
From: Stephen Smalley @ 2016-09-15 14:09 UTC (permalink / raw)
  To: Jason Zaman, selinux

On 09/15/2016 03:15 AM, Jason Zaman wrote:
> Hi All,
> 
> I have kerberized NFSv4 between my laptop and server and when I use
> vers=4.2 I cannot access the mount. It looks like the fcontext needs to
> be invalidated or re-checked or something but I'm not familiar with
> kernel internals so not sure how to fix it (If someone can point me to
> the place, I'd love to get my hands dirty).
> 
> Steps to repro:
> kinit works fine
> mount /home/jason/bregalad works fine, the fstab line is:
> bregalad.perfinion.com:/jason /home/jason/bregalad nfs4 noauto,users,vers=4.2,sec=krb5p,rw,intr,soft,timeo=100,_netdev,fsc 0 0
> 
> Once mounted as my normal user:
> $ ls -aldZ /home/jason/bregalad
> ls: cannot access /home/jason/bregalad: Permission denied
> 
> I get the following denial:
> type=AVC msg=audit(1473923050.591:1577): avc:  denied  { getattr } for  pid=7630 comm="ls" path="/home/jason/bregalad" dev="0:55" ino=4 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
> type=SYSCALL msg=audit(1473923050.591:1577): arch=c000003e syscall=6 success=no exit=-13 a0=399b2bc22f2 a1=7a03d6e960 a2=7a03d6e960 a3=7a02aa8d7b items=1 ppid=6440 pid=7630 auid=1000 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=pts3 ses=5 comm="ls" exe="/bin/ls" subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null)
> type=CWD msg=audit(1473923050.591:1577):  cwd="/home/jason"
> type=PATH msg=audit(1473923050.591:1577): item=0 name="/home/jason/bregalad" inode=4 dev=00:37 mode=040711 ouid=1000 ogid=100 rdev=00:00 obj=system_u:object_r:unlabeled_t:s0 nametype=NORMAL
> type=PROCTITLE msg=audit(1473923050.591:1577): proctitle=6C73002D46002D2D636F6C6F723D6175746F002D616C645A002F686F6D652F6A61736F6E2F62726567616C6164
> 
> If I ls with sysadm_t (which has permissions for unlabeled_t) then the
> fcontext swaps to what it should be and everything works after that as
> staff_t too. I have not had issues with other dirs/files inside the NFS
> mount, only the mountpoint has this issue. 
> 
> As root / sysadm_t: # ls -aldZ /home/jason/bregalad
> drwx--x--x. 50 jason users staff_u:object_r:user_home_dir_t:s0 84 Sep 13 22:38 /home/jason/bregalad/
> As jason / staff_t: $ ls -aldZ /home/jason/bregalad
> drwx--x--x. 50 jason users staff_u:object_r:user_home_dir_t:s0 84 Sep 13 22:38 /home/jason/bregalad/
> 
> $ uname -a
> Linux meriadoc 4.7.2-hardened-r1 #1 SMP PREEMPT Sat Sep 3 11:27:29 SGT 2016 x86_64 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz GenuineIntel GNU/Linux
> I'm on gentoo hardened but dont think GRSec is responsible here. I also had the same problem back on 4.4.
> 
> Is there anything else that can help track this down?
> -- Jason

Maybe we need to add a call to security_inode_invalidate_secctx() in the
nfs code to invalidate the label on the mountpoint directory and force
SELinux to re-fetch it upon the next use?  Presently only gfs2 has been
updated to use that hook.  Technically, NFS should be using it whenever
the cached information may be invalid (e.g. label change on the server
from another client).

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NFSv4.2 unlabeled_t on mountpoints
  2016-09-15 14:09 ` Stephen Smalley
@ 2016-09-15 16:36   ` Dave Quigley
  0 siblings, 0 replies; 4+ messages in thread
From: Dave Quigley @ 2016-09-15 16:36 UTC (permalink / raw)
  To: Stephen Smalley, steved; +Cc: Jason Zaman, selinux

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

Its possible that we dropped something when we got the final patch set
which was accepted in the kernel but I don't remember encountering this
problem. I've included Steve Dickson who took over a lot of the porting
work sometime around the 3.27-3.30 timeframe and was the one to dragged
Labeled NFS across the finish line. He might have some more insight. Look
at whats here and what Steve Smalley said I'd agree with that assessment.
We did something with regard to invalidating cached information in the 4.2
spec but I can't remember how it was resolved and how and if we implemented
it in the Linux client/server/

Dave

On Thu, Sep 15, 2016 at 10:09 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 09/15/2016 03:15 AM, Jason Zaman wrote:
> > Hi All,
> >
> > I have kerberized NFSv4 between my laptop and server and when I use
> > vers=4.2 I cannot access the mount. It looks like the fcontext needs to
> > be invalidated or re-checked or something but I'm not familiar with
> > kernel internals so not sure how to fix it (If someone can point me to
> > the place, I'd love to get my hands dirty).
> >
> > Steps to repro:
> > kinit works fine
> > mount /home/jason/bregalad works fine, the fstab line is:
> > bregalad.perfinion.com:/jason /home/jason/bregalad nfs4
> noauto,users,vers=4.2,sec=krb5p,rw,intr,soft,timeo=100,_netdev,fsc 0 0
> >
> > Once mounted as my normal user:
> > $ ls -aldZ /home/jason/bregalad
> > ls: cannot access /home/jason/bregalad: Permission denied
> >
> > I get the following denial:
> > type=AVC msg=audit(1473923050.591:1577): avc:  denied  { getattr } for
> pid=7630 comm="ls" path="/home/jason/bregalad" dev="0:55" ino=4
> scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
> > type=SYSCALL msg=audit(1473923050.591:1577): arch=c000003e syscall=6
> success=no exit=-13 a0=399b2bc22f2 a1=7a03d6e960 a2=7a03d6e960
> a3=7a02aa8d7b items=1 ppid=6440 pid=7630 auid=1000 uid=1000 gid=100
> euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=pts3 ses=5
> comm="ls" exe="/bin/ls" subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023
> key=(null)
> > type=CWD msg=audit(1473923050.591:1577):  cwd="/home/jason"
> > type=PATH msg=audit(1473923050.591:1577): item=0
> name="/home/jason/bregalad" inode=4 dev=00:37 mode=040711 ouid=1000
> ogid=100 rdev=00:00 obj=system_u:object_r:unlabeled_t:s0 nametype=NORMAL
> > type=PROCTITLE msg=audit(1473923050.591:1577): proctitle=
> 6C73002D46002D2D636F6C6F723D6175746F002D616C645A002F686F6D65
> 2F6A61736F6E2F62726567616C6164
> >
> > If I ls with sysadm_t (which has permissions for unlabeled_t) then the
> > fcontext swaps to what it should be and everything works after that as
> > staff_t too. I have not had issues with other dirs/files inside the NFS
> > mount, only the mountpoint has this issue.
> >
> > As root / sysadm_t: # ls -aldZ /home/jason/bregalad
> > drwx--x--x. 50 jason users staff_u:object_r:user_home_dir_t:s0 84 Sep
> 13 22:38 /home/jason/bregalad/
> > As jason / staff_t: $ ls -aldZ /home/jason/bregalad
> > drwx--x--x. 50 jason users staff_u:object_r:user_home_dir_t:s0 84 Sep
> 13 22:38 /home/jason/bregalad/
> >
> > $ uname -a
> > Linux meriadoc 4.7.2-hardened-r1 #1 SMP PREEMPT Sat Sep 3 11:27:29 SGT
> 2016 x86_64 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz GenuineIntel GNU/Linux
> > I'm on gentoo hardened but dont think GRSec is responsible here. I also
> had the same problem back on 4.4.
> >
> > Is there anything else that can help track this down?
> > -- Jason
>
> Maybe we need to add a call to security_inode_invalidate_secctx() in the
> nfs code to invalidate the label on the mountpoint directory and force
> SELinux to re-fetch it upon the next use?  Presently only gfs2 has been
> updated to use that hook.  Technically, NFS should be using it whenever
> the cached information may be invalid (e.g. label change on the server
> from another client).
>

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-09-15 16:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-15  7:15 NFSv4.2 unlabeled_t on mountpoints Jason Zaman
2016-09-15 14:00 ` Dominick Grift
2016-09-15 14:09 ` Stephen Smalley
2016-09-15 16:36   ` Dave Quigley

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.