Please support NSF squashing multiple groups

Please support NSF squashing multiple groups

[paul.szabo]

Dear Linux-NFS people,

NFS has always had the root_squash option, to protect against a remote
and possibly evil root. NFS should also protect all privileged, or at
least all root-equivalent, UIDs and GIDs. Many UNIX distributions have
root-equivalent GIDs, groups whose members could easily become root,
some listed in http://bugs.debian.org/299007#219 .

Currently, NFS has no ways to protect privileged UIDs and GIDs other
than root himself. Such options should be implemented, to make NFS
safer and more useful. As I understand it, the hold-up is not within
NFS code, but with kernel interfaces not supporting lists of squashed
entities. I am asking you to devise and implement such interfaces.

References:
http://bugs.debian.org/299007
http://bugs.debian.org/384922
http://bugs.debian.org/538392
https://bugzilla.kernel.org/show_bug.cgi?id=14295

Thanks, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Re: Please support NSF squashing multiple groups

[NeilBrown]

On Fri, 19 Aug 2011 10:32:03 +1000 paul.szabo@sydney.edu.au wrote:

> Dear Linux-NFS people,
> 
> NFS has always had the root_squash option, to protect against a remote
> and possibly evil root. NFS should also protect all privileged, or at
> least all root-equivalent, UIDs and GIDs. Many UNIX distributions have
> root-equivalent GIDs, groups whose members could easily become root,
> some listed in http://bugs.debian.org/299007#219 .
> 
> Currently, NFS has no ways to protect privileged UIDs and GIDs other
> than root himself. Such options should be implemented, to make NFS
> safer and more useful. As I understand it, the hold-up is not within
> NFS code, but with kernel interfaces not supporting lists of squashed
> entities. I am asking you to devise and implement such interfaces.
> 
> References:
> http://bugs.debian.org/299007
> http://bugs.debian.org/384922
> http://bugs.debian.org/538392
> https://bugzilla.kernel.org/show_bug.cgi?id=14295
> 
> Thanks, Paul
> 
> Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of Sydney    Australia

Hi Paul,

 I would be much more inclined to go the other way and remove the root_squash
 option so that nothing is squashed.  It is not really a clever idea and
 doesn't really do anything useful - partly because as you note there are
 other uids that can be dangerous.

 If you are using kerberos authentication then you should be able to trust
 that any remote user really is who they say they are, and if you aren't then
 maybe you should be .... we really are running out of excuses to use
 kerberos and it is really quite easy (even I could set it up in half an
 hour!).

 If you are using NFSv4 and kerberos than there already exist interfaces to
 do what you want. See "man idmap.conf".  You can write a plugin that maps a
 textual user or group name to a numeric id number.  So you can squash
 anything that you want to squash, and squash it in any way that you like.

 Does that help?

NeilBrown

Re: Please support NSF squashing multiple groups

[paul.szabo]

Dear Neil,

> If you are using kerberos authentication then you should be able
> to trust that any remote user really is who they say they are ...

Does that "work" also against the "evil remote root" e.g. when the
remote machine is compromised?

> If you are using NFSv4 and kerberos than there already exist
> interfaces to do what you want. See "man idmap.conf". ...

Sorry I do not use NFSv4 or kerberos, yet. Could you please point me
to references about idmap.conf, the ones I found suggest it only takes
[Mapping] settings for Nobody-User and Nobody-Group.


I agree with you that root_squash as currently implemented is rather
limited and useless, but am hoping that it can be improved.


Thanks for your help, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Re: Please support NSF squashing multiple groups

[J. Bruce Fields]

On Fri, Aug 19, 2011 at 12:10:34PM +1000, paul.szabo@sydney.edu.au wrote:
> > If you are using kerberos authentication then you should be able
> > to trust that any remote user really is who they say they are ...
> 
> Does that "work" also against the "evil remote root" e.g. when the
> remote machine is compromised?

It does what's possible.  If a user gives their credentials to the
compromised client--well, what can you do, the attacker has their
credentials at that point.  So if everyone in your department logs into
the same client, then root on that client is going to be able to
impersonate any of them.  Nothing you can do about that.

On the other hand, if several people each have their own client and only
log in to their own clients, and if one of the clients is compromised,
then that client isn't going to be able to impersonate users that have
never given it any credentials.

> > If you are using NFSv4 and kerberos than there already exist
> > interfaces to do what you want. See "man idmap.conf". ...
> 
> Sorry I do not use NFSv4 or kerberos, yet. Could you please point me
> to references about idmap.conf, the ones I found suggest it only takes
> [Mapping] settings for Nobody-User and Nobody-Group.

Look for "static" in a recent version of the idmapd.conf man page.

--b.

Re: Please support NSF squashing multiple groups

[paul.szabo]

Dear Bruce,

>> Does that "work" also against the "evil remote root" e.g. when the
>> remote machine is compromised?
>
> ... Nothing you can do about that.

Thanks for the confirmation.

> ... if several people each have their own client ...

Not my situation.

>>> If you are using NFSv4 and kerberos than there already exist
>>> interfaces to do what you want. See "man idmap.conf". ...
>> 
>> Sorry I do not use NFSv4 or kerberos, yet. ...
>
> Look for "static" in a recent version of the idmapd.conf man page.

Thanks for the hint. Still, [Static] seems to translate UIDs only, seems
to need umich_ldap and [UMICH_SCHEMA] for group memberships. Maybe
idmapd ignores group membership lists as received from the client and
sets the "local" list for each UID? - I guess I will need to investigate
further how NFSv4 and idmapd work and try to implement them on my
network.

Thanks, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Re: Please support NSF squashing multiple groups

[Andy Adamson]

On Aug 19, 2011, at 6:06 PM, paul.szabo@sydney.edu.au wrote:

> Dear Bruce,
> 
>>> Does that "work" also against the "evil remote root" e.g. when the
>>> remote machine is compromised?
>> 
>> ... Nothing you can do about that.
> 
> Thanks for the confirmation.
> 
>> ... if several people each have their own client ...
> 
> Not my situation.
> 
>>>> If you are using NFSv4 and kerberos than there already exist
>>>> interfaces to do what you want. See "man idmap.conf". ...
>>> 
>>> Sorry I do not use NFSv4 or kerberos, yet. ...
>> 
>> Look for "static" in a recent version of the idmapd.conf man page.
> 
> Thanks for the hint. Still, [Static] seems to translate UIDs only, seems
> to need umich_ldap and [UMICH_SCHEMA] for group memberships. Maybe
> idmapd ignores group membership lists as received from the client and
> sets the "local" list for each UID? - I guess I will need to investigate
> further how NFSv4 and idmapd work and try to implement them on my
> network.

Note that only AUTH_SYS sends GID and GID lists in the rpc_cred. RPCSEC_GSS with Kerberos only sends the krb5 principal to the server. The server looks up group membership via nsswitch - either /etc/groups, or ldap. Note ldap requires a secure communication usually with an X.509 certificate. NIS is not recommended for use with kerberos.

idmapd only deals with groups when a SETATTR arrives with ACE who's that are group names where it maps the groupname@domain to a gid, or a GETATTR ACL request where it maps gid->groupname@domain

-->Andy

> 
> Thanks, Paul
> 
> Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of Sydney    Australia
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Please support NSF squashing multiple groups

[paul.szabo]

Dear Andy,

> Note that only AUTH_SYS sends GID and GID lists in the rpc_cred.
> RPCSEC_GSS with Kerberos only sends the krb5 principal to the server.
> The server looks up group membership via nsswitch - either /etc/groups
> ...

Can the server be set so as to ignore any AUTH_SYS sends, and accept
RPCSEC_GSS only?

> idmapd only deals with groups when a SETATTR arrives with ACE who's that
> are group names where it maps the groupname@domain to a gid, or a
> GETATTR ACL request where it maps gid->groupname@domain

Can the server be set so as to ignore any attempts from the client to
set group memberships, but always set its own from /etc/group?

Thanks, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Re: Please support NSF squashing multiple groups

[J. Bruce Fields]

On Sat, Aug 20, 2011 at 08:35:43AM +1000, paul.szabo@sydney.edu.au wrote:
> Dear Andy,
> 
> > Note that only AUTH_SYS sends GID and GID lists in the rpc_cred.
> > RPCSEC_GSS with Kerberos only sends the krb5 principal to the server.
> > The server looks up group membership via nsswitch - either /etc/groups
> > ...
> 
> Can the server be set so as to ignore any AUTH_SYS sends, and accept
> RPCSEC_GSS only?

Add something like sec=krb5:krb5i:krb5p to all your exports.

> > idmapd only deals with groups when a SETATTR arrives with ACE who's that
> > are group names where it maps the groupname@domain to a gid, or a
> > GETATTR ACL request where it maps gid->groupname@domain
> 
> Can the server be set so as to ignore any attempts from the client to
> set group memberships, but always set its own from /etc/group?

Use kerberos, or run mountd with the --manage-gids option.

--b.

Re: Please support NSF squashing multiple groups

[NeilBrown]

On Fri, 19 Aug 2011 19:45:34 -0400 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Sat, Aug 20, 2011 at 08:35:43AM +1000, paul.szabo@sydney.edu.au wrote:
> > Dear Andy,
> > 
> > > Note that only AUTH_SYS sends GID and GID lists in the rpc_cred.
> > > RPCSEC_GSS with Kerberos only sends the krb5 principal to the server.
> > > The server looks up group membership via nsswitch - either /etc/groups
> > > ...
> > 
> > Can the server be set so as to ignore any AUTH_SYS sends, and accept
> > RPCSEC_GSS only?
> 
> Add something like sec=krb5:krb5i:krb5p to all your exports.
> 
> > > idmapd only deals with groups when a SETATTR arrives with ACE who's that
> > > are group names where it maps the groupname@domain to a gid, or a
> > > GETATTR ACL request where it maps gid->groupname@domain
> > 
> > Can the server be set so as to ignore any attempts from the client to
> > set group memberships, but always set its own from /etc/group?
> 
> Use kerberos, or run mountd with the --manage-gids option.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I almost suggested this, but then realised that it doesn't help.

With AUTH_SYS the client sends a UID, a GID and a list of at most 16
auxiliary GIDs.

With --manage-gids, the server ignores the list of auxiliary GIDs and
generates a list locally based on the UID.
So the UID and primary GID from the server are still trusted.

So kerberos is really the only option to be able to filter uids and gids
under user-space control.

When I suggested looking at idmap I was actually imagining writing your own
plug-in that did whatever mapping and filtering you wanted.

I think I mentioned before that you would need to use kerberos and NFSv4 to
make use of this but in fact you just need kerberos.  It will work with
NFSv3, though with some limitations.
In particular:
  when the client issues a chown/chgrp request, the uid/gid is used directly
  - idmap does not have a chance to filter/translate it (in v4 it does).
  When the client issues a getattr, the uid/gid are passed through
  unchanged.  idmap does not get to translate it (in v4 it does).

The only mapping available with v3 is the authenticated username of the
entity which issued the request.  idmap gets to translate that into a uid and
gids however the plug-in tells it too.

NeilBrown


> 
> --b.

Re: Please support NSF squashing multiple groups

[Andy Adamson]

On Aug 19, 2011, at 6:35 PM, paul.szabo@sydney.edu.au wrote:

> Dear Andy,
> 
>> Note that only AUTH_SYS sends GID and GID lists in the rpc_cred.
>> RPCSEC_GSS with Kerberos only sends the krb5 principal to the server.
>> The server looks up group membership via nsswitch - either /etc/groups
>> ...
> 
> Can the server be set so as to ignore any AUTH_SYS sends, and accept
> RPCSEC_GSS only?

For now, yes. Use sec=krb5 and/or krb5i,krb5p export options without sec=sys.
> 
>> idmapd only deals with groups when a SETATTR arrives with ACE who's that
>> are group names where it maps the groupname@domain to a gid, or a
>> GETATTR ACL request where it maps gid->groupname@domain
> 
> Can the server be set so as to ignore any attempts from the client to
> set group memberships, but always set its own from /etc/group?

This is the only behavior the Linux server currently has with Kerberos - it always queries it's local view of group membership.

Note that if the Windows Active Directory is used as a Kerberos KDC, it adds an authorization payload to the Kerberos ticket (a PAC) which contains a user's group memberships.  There is an effort to add a similar payload to MIT KDC. The Linux server will eventually be able to use this information to avoid a local call to obtain group memberships.

-->Andy

> 
> Thanks, Paul
> 
> Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of Sydney    Australia

Re: Please support NSF squashing multiple groups

[J. Bruce Fields]

On Fri, Aug 19, 2011 at 10:32:03AM +1000, paul.szabo@sydney.edu.au wrote:
> Dear Linux-NFS people,
> 
> NFS has always had the root_squash option, to protect against a remote
> and possibly evil root. NFS should also protect all privileged, or at
> least all root-equivalent, UIDs and GIDs. Many UNIX distributions have
> root-equivalent GIDs, groups whose members could easily become root,
> some listed in http://bugs.debian.org/299007#219 .

Hm.  It depends on what you're using the exports for, I suppose.  If the
server exports something it doesn't itself use for anything important
then the server should be safe against clients.  The clients though may
be able to attack each other if say /usr/bin is mounted over NFS and
is writeable by some non-root group.  OK, I guess that's what you're
saying.

> Currently, NFS has no ways to protect privileged UIDs and GIDs other
> than root himself. Such options should be implemented, to make NFS
> safer and more useful. As I understand it, the hold-up is not within
> NFS code, but with kernel interfaces not supporting lists of squashed
> entities. I am asking you to devise and implement such interfaces.

That's not a small project, so we'd need a volunteer.  As Neil says
kerberos might also help.

--b.

Re: Please support NSF squashing multiple groups

[paul.szabo]

Dear Bruce,

>> NFS has always had the root_squash option, to protect against a remote
>> and possibly evil root. NFS should also protect all privileged, or at
>> least all root-equivalent, UIDs and GIDs. Many UNIX distributions have
>> root-equivalent GIDs, groups whose members could easily become root,
>> some listed in http://bugs.debian.org/299007#219 .
>
> Hm.  It depends on what you're using the exports for, I suppose.  If the
> server exports something it doesn't itself use for anything important
> then the server should be safe against clients.  The clients though may
> be able to attack each other if say /usr/bin is mounted over NFS and
> is writeable by some non-root group.  OK, I guess that's what you're
> saying.

Sorry, no.

There would be some protection if users could not log in to the server
or some clients. My setup includes user login access to the server and
to clients, so the attacker creating a setgid (group staff or disk or
similar) /users/my/file is sufficient for a compromise of the server or
any clients.

There would be some protection if the server or clients had the relevant
filesystems mounted nosuid or noexec, but in my setup users need to be
able to create setuid-to-themselves executables.

>> Currently, NFS has no ways to protect privileged UIDs and GIDs other
>> than root himself. Such options should be implemented, to make NFS
>> safer and more useful. As I understand it, the hold-up is not within
>> NFS code, but with kernel interfaces not supporting lists of squashed
>> entities. I am asking you to devise and implement such interfaces.
>
> That's not a small project, so we'd need a volunteer.  As Neil says
> kerberos might also help.

I realize this is not an easy project.

I will investigate NFSv4 and kerberos.

Thanks, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Re: Please support NSF squashing multiple groups

[Jim Rees]

Paul, it's good to hear from you.  Been about 12 years.

AUTH_SYS provides what some people call "pretend security."  The server
enforces a security policy based on user and group IDs.  But it only
pretends to enforce the policy, because it allows clients to break the rules
if they want.

Some people claim this is useless, and AUTH_SYS should go away, to be
replaced by "none" or "kerberos."  I disagree.  It's useful for preventing
mistakes among a group of users who trust each other but sometimes get
sloppy.  My home network would be a good example.  A compute cluster might
be another.

I do find root_squash useful but I'm not sure there's much point in adding
more squash options.  For one thing it might lull people into thinking
they're getting something more than just pretend security.  If you have
users who might try to break in to a machine by setting setgid bits, then
AUTH_SYS is not for you.

Re: Please support NSF squashing multiple groups

[paul.szabo-E0wInbZyfUpWG/WdbR7gnQ]

(Hi Jim!)
At the moment I am trying to install/configure NFSv4 (not as easy as
should be!), then test. Will report on linux-nfs soon (?!).

Thanks to all for the help, Paul

Paul Szabo   psz-nc3JQ54Db24SRaQb/UD1RYdd74u8MsAO@public.gmane.org   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Re: Please support NSF squashing multiple groups

[paul.szabo]

Dear all,

I wrote about some security issues with NFS, about protecting against
privileged UIDs and GIDs, like root_squash protects against root.

Your advice was to use NFSv4 with kerberos authentication. I now
succeeded in setting that up on a test system; though not as simple as
should be, it seems to work as expected. The changes required for use
are non-trivial, so I will not immediately be able to use it.

Seems that the mountd option --manage-gids handles the secondary groups
only. I still do not quite understand why mountd (with that or another
option) cannot handle the primary GID also, setting it to the GID
corresponding to the UID on the server; and maybe even "squash" any UIDs
in a table similar to idmap, or simply squash UIDs less than UID_MIN
(squash directly, without any kernel interaction). Could you please tell
me whether those are conceptually possible?

Thanks, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

Re: Please support NSF squashing multiple groups

[Trond Myklebust]

On Wed, 2011-09-21 at 08:48 +1000, paul.szabo@sydney.edu.au wrote: 
> Dear all,
> 
> I wrote about some security issues with NFS, about protecting against
> privileged UIDs and GIDs, like root_squash protects against root.
> 
> Your advice was to use NFSv4 with kerberos authentication. I now
> succeeded in setting that up on a test system; though not as simple as
> should be, it seems to work as expected. The changes required for use
> are non-trivial, so I will not immediately be able to use it.
> 
> Seems that the mountd option --manage-gids handles the secondary groups
> only. I still do not quite understand why mountd (with that or another
> option) cannot handle the primary GID also, setting it to the GID
> corresponding to the UID on the server; and maybe even "squash" any UIDs
> in a table similar to idmap, or simply squash UIDs less than UID_MIN
> (squash directly, without any kernel interaction). Could you please tell
> me whether those are conceptually possible?

Secondary groups are all about granting permission to perform certain
operations that are restricted to users of that group.

The _primary_ group is about the above _plus_ it has a role when you are
creating new objects, where it defines the 'group' owner of that object.
Your proposal would screw up utilities which call the 'setgid()' or
'setfsgid()' functions before creating files or directories that need to
have very specific group ownerships.

IOW: what you are proposing is a potential security problem.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

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

Re: Please support NSF squashing multiple groups

[paul.szabo]

Dear Trond,

> ... what you are proposing is a potential security problem.

Yes, definitely: if ever such options were implemented, then potential
users should evaluate whether using them (or not using them) introduced
a security vulnerability. That said...

NFS security traditionally depended on UIDs and GIDs being "in sync"
between the server and the clients. My proposal simply would enforce
all GIDs to be "in sync" with the UID, as per server view; most often
that would be a no-op (except for accesses by setuid or setgid apps).

Seems that kerberos has no concept of groups but only of "principals"
which are somewhat like UIDs. My proposal would bring NFSv3 in line
with the NFSv4+krb model of "only the UID matters".

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

RE: Please support NSF squashing multiple groups

[Myklebust, Trond]

> -----Original Message-----
> From: paul.szabo@sydney.edu.au [mailto:paul.szabo@sydney.edu.au]
> Sent: Tuesday, September 20, 2011 7:29 PM
> To: Myklebust, Trond
> Cc: linux-nfs@vger.kernel.org
> Subject: Re: Please support NSF squashing multiple groups
> 
> Dear Trond,
> 
> > ... what you are proposing is a potential security problem.
> 
> Yes, definitely: if ever such options were implemented, then potential
users
> should evaluate whether using them (or not using them) introduced a
> security vulnerability. That said...
> 
> NFS security traditionally depended on UIDs and GIDs being "in sync"
> between the server and the clients. My proposal simply would enforce
all
> GIDs to be "in sync" with the UID, as per server view; most often that
would
> be a no-op (except for accesses by setuid or setgid apps).
> 
> Seems that kerberos has no concept of groups but only of "principals"
> which are somewhat like UIDs. My proposal would bring NFSv3 in line
with
> the NFSv4+krb model of "only the UID matters".

That's a model which is incompatible with the way many people use the
AUTH_SYS authentication model.

NFSroot setups etc _rely_ on being able to setgid() at will. They may
also require the group hack in order to work in environments where some
people have > 32 groups.

Basically, the point is this: AUTH_SYS is inherently for use only in
trusted environments. It is too easy to fake a uid or a gid when you use
a protocol that exposes them in clear on the network and without
providing any form of secure integrity checking.

Kerberos is able to go beyond that trusted model (although it too has
limitations - particularly w.r.t. working in an environment where the
client or the server may have been compromised). However Kerberos will
currently limit your ability to setgid. The next generation of
RPCSEC_GSS is expected to lift that particular limitation, and will
allow us to bring kerberos in line with AUTH_SYS (albeit with greater
security) rather than the other way round.

Cheers
  Trond

RE: Please support NSF squashing multiple groups

[paul.szabo]

Dear Trond,

> That's a model which is incompatible with the way many people use
> the AUTH_SYS authentication model.

That is why I only propose (hope for) mountd options which might be
used by some people, and others might leave turned off.

> ... It is too easy to fake a uid or a gid when you use a protocol
> that exposes them in clear on the network ...

Trivial to find out what they are, may not be so easy to inject them.

---

> ... I don't at all understand your threat model. You appear to be
> worried about a threat where a user can somehow usurp gids but not
> uids on the client.

I am worried about an attacker being able to "do anything" on the
client (having "cracked root" on it).

In terms of usurping UIDs, he is pretty much defeated: the only
privileged UID is root, rendered harmless by root_squash. (Beware
that other UIDs e.g. bin or sys may be dangerous on some systems:
root_squash as currently implemented is incomplete, insecure.)

There is currently no such protection for usurping GIDs, and some
(e.g. staff for Debian, or disk shadow etc) are privileged and
root-equivalent. We need protection, similar to root_squash.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

RE: Please support NSF squashing multiple groups

[Myklebust, Trond]

> -----Original Message-----
> From: paul.szabo@sydney.edu.au [mailto:paul.szabo@sydney.edu.au]
> Sent: Tuesday, September 20, 2011 8:10 PM
> To: Myklebust, Trond
> Cc: linux-nfs@vger.kernel.org
> Subject: RE: Please support NSF squashing multiple groups
> 
> > ... It is too easy to fake a uid or a gid when you use a protocol
that
> > exposes them in clear on the network ...
> 
> Trivial to find out what they are, may not be so easy to inject them.

If you are inside the network? All you need is a client and sufficient
privileges to open a privileged port. You get bonus points if you can
also compromise a router/switch...
 
> > ... I don't at all understand your threat model. You appear to be
> > worried about a threat where a user can somehow usurp gids but not
> > uids on the client.
> 
> I am worried about an attacker being able to "do anything" on the
client
> (having "cracked root" on it).
>
> In terms of usurping UIDs, he is pretty much defeated: the only
privileged
> UID is root, rendered harmless by root_squash. (Beware that other UIDs
e.g.
> bin or sys may be dangerous on some systems:
> root_squash as currently implemented is incomplete, insecure.)

Ermm... If you can spoof any user (except root), then surely there are
several alternatives open to you. If home directories are on NFS, then I
can imagine installing ssh keys to enable me to log on to any client in
the system, or setting up spoofed .profile files.

Alternatively, poisoning their namespace with a well placed symlink, or 

> There is currently no such protection for usurping GIDs, and some
(e.g. staff
> for Debian, or disk shadow etc) are privileged and root-equivalent. We
need
> protection, similar to root_squash.

Root squashing will automatically also squash gid==0 (whether or not the
uid == 0).

The problem you are describing is different: you have a _list_ of
privileged gids that you want to squash for some reason.  I could
probably find an equivalent list of privileged uids on most systems that
you don't ever want the client to spoof (e.g. 'bin', 'daemon',
'dbus',...).
There are 2 solutions to that problem: either go the route of the
rpc.ugidd daemon, which does general mapping from one set of uid/gids to
another. Alternatively, don't expose anything which is protected by a
privileged uid or gid...

Cheers
    Trond

RE: Please support NSF squashing multiple groups

[paul.szabo]

Dear Trond,

>>> ... It is too easy to fake a uid or a gid when you use a protocol that
>>> exposes them in clear on the network ...
>> Trivial to find out what they are, may not be so easy to inject them.
>
> If you are inside the network? All you need is a client and sufficient
> privileges to open a privileged port. ...

Inside "the network", but on the wrong subnet.

>> In terms of usurping UIDs, he is pretty much defeated ... rendered
>> harmless by root_squash. ...
>
> Ermm... If you can spoof any user (except root), then surely there are
> several alternatives open to you. ...

I am not worried about attackers getting access to the data of another
user, but about "getting root" on the server or another client:
  ... the attacker creating a setgid (group staff or disk or similar)
  /users/my/file is sufficient for a compromise ...
as mentioned in
http://www.spinics.net/lists/linux-nfs/msg23481.html

I am aware that the attacker could trojan the files of a user who is
known to log in as root, and so trap and reveal the root password;
or steal the Xauthority from such a user and inject keystrokes to a
rootly window.

> There are 2 solutions to that problem: either go the route of the
> rpc.ugidd daemon ...

Which is not present, does not seem supported on Debian. Also, reading
http://linuxmafia.com/pub/linux/suse-linux-internals/chapter20.html
it sounds like ugidd runs on the client not the server, so is unable to
provide the protection I want. Maybe using map_static would be the way
to go, but is also not supported on Debian.

And anyway this all seems to contradict Neil Brown's message
http://www.spinics.net/lists/linux-nfs/msg23488.html
earlier in this thread saying NFSv3 cannot possibly do things "right".

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

RE: Please support NSF squashing multiple groups

[Myklebust, Trond]

> -----Original Message-----
> From: Myklebust, Trond
> Sent: Tuesday, September 20, 2011 7:39 PM
> To: 'paul.szabo@sydney.edu.au'
> Cc: linux-nfs@vger.kernel.org
> Subject: RE: Please support NSF squashing multiple groups
> 
> > -----Original Message-----
> > From: paul.szabo@sydney.edu.au [mailto:paul.szabo@sydney.edu.au]
> > Sent: Tuesday, September 20, 2011 7:29 PM
> > To: Myklebust, Trond
> > Cc: linux-nfs@vger.kernel.org
> > Subject: Re: Please support NSF squashing multiple groups
> >
> > Dear Trond,
> >
> > > ... what you are proposing is a potential security problem.
> >
> > Yes, definitely: if ever such options were implemented, then
potential
> > users should evaluate whether using them (or not using them)
> > introduced a security vulnerability. That said...
> >
> > NFS security traditionally depended on UIDs and GIDs being "in sync"
> > between the server and the clients. My proposal simply would enforce
> > all GIDs to be "in sync" with the UID, as per server view; most
often
> > that would be a no-op (except for accesses by setuid or setgid
apps).
> >
> > Seems that kerberos has no concept of groups but only of
"principals"
> > which are somewhat like UIDs. My proposal would bring NFSv3 in line
> > with the NFSv4+krb model of "only the UID matters".
> 
> That's a model which is incompatible with the way many people use the
> AUTH_SYS authentication model.
> 
> NFSroot setups etc _rely_ on being able to setgid() at will. They may
also
> require the group hack in order to work in environments where some
people
> have > 32 groups.
> 
> Basically, the point is this: AUTH_SYS is inherently for use only in
trusted
> environments. It is too easy to fake a uid or a gid when you use a
protocol
> that exposes them in clear on the network and without providing any
form of
> secure integrity checking.
> 
> 
> Kerberos is able to go beyond that trusted model (although it too has
> limitations - particularly w.r.t. working in an environment where the
client or
> the server may have been compromised). However Kerberos will currently
> limit your ability to setgid. The next generation of RPCSEC_GSS is
expected to
> lift that particular limitation, and will allow us to bring kerberos
in line with
> AUTH_SYS (albeit with greater security) rather than the other way
round.

Basically, what I'm trying to say is that I don't at all understand your
threat model. You appear to be worried about a threat where a user can
somehow usurp gids but not uids on the client.

Why is that particular case of interest?

Cheers
  Trond

Re: Please support NSF squashing multiple groups

[paul.szabo]

Dear all,

I wrote recently:

  Seems that the mountd option --manage-gids handles the secondary groups
  only. I still do not quite understand why mountd (with that or another
  option) cannot handle the primary GID also, setting it to the GID
  corresponding to the UID on the server; and maybe even "squash" any UIDs
  in a table similar to idmap, or simply squash UIDs less than UID_MIN
  (squash directly, without any kernel interaction). Could you please tell
  me whether those are conceptually possible?

Silly me, should have looked myself! Now I understand that things are
not "done" in mountd, but are in the kernel: the use of those
/proc/net/rpc/%s/channel things is not in the mountd binary, but in the
kernel linux-source-2.6.32/net/sunrpc/svcauth_unix.c . No use setting
things up in mountd, if the kernel does not bother using them.

So it remains that for security, I would need NFSv4 with kerberos.

Thanks for all your help, and apologies for my stubbornness.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia