2:36 a.m.
Hi,
I'm currently working to set up ganesha with kerberos. Everything seems to work as
expected, except that I can't find a way to limit the access that root on the client
has to the mounted filesystem.
At the moment I'm squashing root to 'nobody' - however that obviously still
allows access to world-readable files/dirs. Is there a way to block all FS access from
root/nobody, or always require a valid kerberos ticket?
Thanks,
Matthew
5:45 a.m.
Why should root have less access than any other user?
Daniel
On 9/5/22 05:36, Matthew Richardson wrote:
Hi,
I'm currently working to set up ganesha with kerberos. Everything seems to work as
expected, except that I can't find a way to limit the access that root on the client
has to the mounted filesystem.
At the moment I'm squashing root to 'nobody' - however that obviously still
allows access to world-readable files/dirs. Is there a way to block all FS access from
root/nobody, or always require a valid kerberos ticket?
Thanks,
Matthew
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org
6 a.m.
On Tue, Sep 6, 2022 at 8:51 AM Daniel Gryniewicz <dang(a)redhat.com> wrote:
Why should root have less access than any other user?
Daniel
On 9/5/22 05:36, Matthew Richardson wrote:
> Hi,
>
> I'm currently working to set up ganesha with kerberos. Everything seems to work
as expected, except that I can't find a way to limit the access that root on the
client has to the mounted filesystem.
>
> At the moment I'm squashing root to 'nobody' - however that obviously
still allows access to world-readable files/dirs. Is there a way to block all FS access
from root/nobody, or always require a valid kerberos ticket?
>
If you want to restrict root's access to a file system, and root is
squashed/mapped to "nobody", you need to restrict "nobody's"
access to
the filesystem. This is just the way it works. Essentially, if you
have the "other" permissions (or ACLs) on a file set to allow access,
then anyone can get access - this is how POSIX permissions work. If
you don't want everyone - including a remote "root" user - to have
access, restrict the permissions accordingly.
-Nick
8:35 a.m.
On Tue, Sep 6, 2022 at 8:51 AM Daniel Gryniewicz
<dang(a)redhat.com> wrote:
>
> Why should root have less access than any other user?
Yes, what is the requirement here?
> On 9/5/22 05:36, Matthew Richardson wrote:
> > Hi,
> >
> > I'm currently working to set up ganesha with kerberos. Everything seems to
work as expected, except that I can't find a way to limit the access that root on
the client has to the mounted filesystem.
> >
> > At the moment I'm squashing root to 'nobody' - however that
obviously still
allows access to world-readable files/dirs. Is there a way to block all FS access
from root/nobody, or always require a valid kerberos ticket?
Does root have a valid Kerberos ticket?
If you want to restrict root's access to a file system, and root
is
squashed/mapped to "nobody", you need to restrict "nobody's"
access to the
filesystem. This is just the way it works. Essentially, if you have the
"other"
permissions (or ACLs) on a file set to allow access, then anyone can get access -
this is how POSIX permissions work. If you don't want everyone - including a
remote "root" user - to have access, restrict the permissions accordingly.
Yes, definitely. Note that directory permissions are not sufficient to protect files since
a client could "guess" a file handle and access any inode on an exported file
system (even an inode in a portion of the file system that is outside an exported sub-tree
of the file system).
Frank
8:56 a.m.
Yes, what is the requirement here?
The issue is really a security one. Initial connections are only 'protected' by
Client config limited to host/ip ranges. If someone can 'reach' the NFS server
then they can connect as root (nobody) and potentially access anything which is
world-readable. This is obviously a 'classic' issue with ip-based auth on NFS, and
I was hoping that the existence of kerberos authentication helped here. Perhaps not.
Yes, definitely. Note that directory permissions are not sufficient
to protect files since
a client could "guess" a file handle and access any inode on an exported file
system (even an inode in a portion of the file system that is outside an exported
sub-tree
of the file system).
Indeed - the top-level directory has to be world-executable, which then opens up attacks
through guessing paths/filenames.
I suppose we could set some top-level ACLs to explicitly restrict the 'nobody'
user to have no access, but I was hoping that there might be a nicer way for the server to
just reject all FS requests for certain users.
6:27 a.m.
You can always change SecType to only allow krb5 authentication. Then
no one can connect without a kerberos ticket.
Daniel
On 9/6/22 11:56, Matthew Richardson wrote:
> Yes, what is the requirement here?
The issue is really a security one. Initial connections are only 'protected' by
Client config limited to host/ip ranges. If someone can 'reach' the NFS server
then they can connect as root (nobody) and potentially access anything which is
world-readable. This is obviously a 'classic' issue with ip-based auth on NFS, and
I was hoping that the existence of kerberos authentication helped here. Perhaps not.
> Yes, definitely. Note that directory permissions are not sufficient to protect files
since
> a client could "guess" a file handle and access any inode on an exported
file
> system (even an inode in a portion of the file system that is outside an exported
sub-tree
> of the file system).
Indeed - the top-level directory has to be world-executable, which then opens up attacks
through guessing paths/filenames.
I suppose we could set some top-level ACLs to explicitly restrict the 'nobody'
user to have no access, but I was hoping that there might be a nicer way for the server to
just reject all FS requests for certain users.
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org
7:54 a.m.
Some things to consider:
Yes, setting SecType to only allow Kerberos will then require a Kerberos ticket for any
access (including NFS v3 mount).
The client may use a service principle for some actions. This I believe maps to root. This
must be allowed during a mount (possible exception, I'm not sure if a mount is
performed by a non-root user if NFS does the mount access then using that user's
credentials). This means that the Ganesha host will have to have each client's service
principle in its keytab which means that isn't a way to exclude root access. The
principle will allow root requests to be accepted, and then squashed.
Note that adding a "RootDeny" squash option would not work since that would at
least prevent an NFSv4 client from mounting a specific export (since the client will do
PUTROOTFH followed by LOOKUP to traverse the pseudofs to the export, all performed as root
or with the service ticket).
It looks like NFSv3 mount is not so constrained (the credentials are not examined, just
the fact that the security flavor is allowed). NOTE: This does mean if a user knows a
directory on the server that is in the exported tree that allows world access, the user
can mount that directory directly and gain access to any files in that directory that then
have world access. At the least, they can list the directory. At least Ganesha does not
allow mounting files (I have in the past used NFS setups where you COULD mount a single
file...).
If using NFS, don't ever assume that permissions in a higher level directory prevent
access to directories and files below them. Each directory or file MUST have appropriate
permissions set.
Frank
-----Original Message-----
From: Daniel Gryniewicz [mailto:dang@redhat.com]
Sent: Wednesday, September 7, 2022 6:27 AM
To: support(a)lists.nfs-ganesha.org
Subject: [NFS-Ganesha-Support] Re: Restricting root's FS access
You can always change SecType to only allow krb5 authentication. Then no one
can connect without a kerberos ticket.
Daniel
On 9/6/22 11:56, Matthew Richardson wrote:
>> Yes, what is the requirement here?
>
> The issue is really a security one. Initial connections are only 'protected'
by
Client config limited to host/ip ranges. If someone can 'reach' the NFS server
then they can connect as root (nobody) and potentially access anything which is
world-readable. This is obviously a 'classic' issue with ip-based auth on NFS,
and
I was hoping that the existence of kerberos authentication helped here. Perhaps
not.
>
>> Yes, definitely. Note that directory permissions are not sufficient
>> to protect files since a client could "guess" a file handle and
>> access any inode on an exported file system (even an inode in a
>> portion of the file system that is outside an exported sub-tree of the file
system).
>
> Indeed - the top-level directory has to be world-executable, which then opens
up attacks through guessing paths/filenames.
>
> I suppose we could set some top-level ACLs to explicitly restrict the
'nobody'
user to have no access, but I was hoping that there might be a nicer way for the
server to just reject all FS requests for certain users.
> _______________________________________________
> Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe
> send an email to support-leave(a)lists.nfs-ganesha.org
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an
email to support-leave(a)lists.nfs-ganesha.org
9:27 a.m.
Some things to consider:
Yes, setting SecType to only allow Kerberos will then require a Kerberos ticket for any
access (including NFS v3 mount).
The client may use a service principle for some actions. This I believe maps to root.
This
must be allowed during a mount (possible exception, I'm not sure if a mount is
performed by a non-root user if NFS does the mount access then using that user's
credentials). This means that the Ganesha host will have to have each client's
service
principle in its keytab which means that isn't a way to exclude root access. The
principle will allow root requests to be accepted, and then squashed.
Many thanks - this post got me digging deeper into the debug logs and what exactly was
happening at mount versus ls on the client, and my previous assumptions on how things were
working was incorrect.
It turns out that the mount is using the client's krb5 'host' principal to
authenticate the mount. Moving the keytab sideways and restarting rpc-gssd means the
client is forbidden from mounting.
So from a security perspective an untrusted machine without a host principal can't
mount at all, which is exactly what I was hoping for.
Any account on the client that doesn't then have it's own krb5 ticket will result
in idmapd on the server squashing them to 'nobody'.
Obviously it would be nice if we could enforce that both the host and the user must have a
valid ticket to get any fs access, but your explanation of why this wouldn't work for
root means this isn't likely to happen. (Though this is really only thinking of
untrusted users on trusted machines, which is a whole different issue security-wise!)
Thanks once again for helping clarify everything!
Matthew
11:55 a.m.
You're welcome. I hope these explanations help you achieve the security you are hoping
for.
Frank
-----Original Message-----
From: Matthew Richardson [mailto:m.richardson@ed.ac.uk]
Sent: Wednesday, September 7, 2022 9:28 AM
To: support(a)lists.nfs-ganesha.org
Subject: [NFS-Ganesha-Support] Re: Restricting root's FS access
> Some things to consider:
>
> Yes, setting SecType to only allow Kerberos will then require a
> Kerberos ticket for any access (including NFS v3 mount).
>
> The client may use a service principle for some actions. This I
> believe maps to root. This must be allowed during a mount (possible
> exception, I'm not sure if a mount is performed by a non-root user if
> NFS does the mount access then using that user's credentials). This
> means that the Ganesha host will have to have each client's service
> principle in its keytab which means that isn't a way to exclude root access.
The
principle will allow root requests to be accepted, and then squashed.
Many thanks - this post got me digging deeper into the debug logs and what
exactly was happening at mount versus ls on the client, and my previous
assumptions on how things were working was incorrect.
It turns out that the mount is using the client's krb5 'host' principal to
authenticate the mount. Moving the keytab sideways and restarting rpc-gssd
means the client is forbidden from mounting.
So from a security perspective an untrusted machine without a host principal
can't mount at all, which is exactly what I was hoping for.
Any account on the client that doesn't then have it's own krb5 ticket will result
in
idmapd on the server squashing them to 'nobody'.
Obviously it would be nice if we could enforce that both the host and the user
must have a valid ticket to get any fs access, but your explanation of why this
wouldn't work for root means this isn't likely to happen. (Though this is really
only thinking of untrusted users on trusted machines, which is a whole different
issue security-wise!)
Thanks once again for helping clarify everything!
Matthew
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an
email to support-leave(a)lists.nfs-ganesha.org
8:29 a.m.
You can always change SecType to only allow krb5 authentication.
Then
no one can connect without a kerberos ticket.
I have the following config at the moment (the SecType in EXPORT is probably redundant,
but is there just to make sure it was being used):
EXPORT {
Export_ID=100;
Protocols = 4;
Transports = TCP;
Path = /;
Pseudo = /nfs;
Access_Type = None;
SecType = krb5;
Squash = root;
CLIENT {
Clients = *;
Access_Type = RW;
SecType = krb5;
}
}
It doesn't appear that kerberos is used at all in order for root to mount the export.
It just means that kerberos/idmap is used to identify the user (with root being squashed
to nobody). Unless I'm missing something?
596
days inactive
598
days old
9 comments
4 participants
participants (4)
-
Daniel Gryniewicz -
Frank Filz -
Matthew Richardson -
Nick Couchman