[Tfug] pcnfsd(8) privilege reduction

[Bexley Hall]

Hi John,

On 1/8/2013 9:28 PM, John Gruenenfelder wrote:
> On Tue, Jan 1, 2013 at 5:07 PM, Bexley Hall<bexley401 at yahoo.com>  wrote:

>> I'm trying to get cross-platform NFS support running between
>> my UN*X boxen and the WindBlows boxes, here (CIFS not an option).
>>
>> To do so, pcnfsd(8) needs to run on the UN*X server(s).  *If*
>> I don't export any printers, can I run it as an unprivileged
>> user?
>>
>> Yeah, I should just dig through the sources but figured someone
>> might already have an answer to this one (given the security
>> issues involved).
>
> Hi Don,
>
> I can't give you a specific answer since I just make use of the Debian
> packaged kernel space NFS daemon.
>
> That said, the standard NFS ports are in the 2000 range, I believe, so
> they are unprivileged.  However, NFS also relies on making heavy use
> of the Sun RPC portmapper which operates on port 111.

Yes.  And, for windows, nlockmgr, statd, etc.

> In the past, Debian used to offer both the user space and kernel space
> NFS daemons, but the former is no longer available, probably due to
> lack of maintenance.  Since it did exist at one point, I assume there
> must be a way to configure the portmapper (on all ends) to use an
> alternate unprivileged port.

Pcnfsd(8) and nfsd(8) have different roles.  I.e., nfsd(8) does
the actual "work" of providing access to the file/filesystem
regardless.  Pcnfsd(8) only has a role when non-UN*X clients
are involved.

When a UN*X user accesses a file, their identity is provided to
the file system via a (uid,gid) "credential" -- the kernel knows
who they are because they identified themselves when they logged in
(username, password).  These are mapped to (uid,gid) and kept with
the user's process(es) while he is logged on.

[This is true even if the user is on a remote UN*X host.  The
kernel *there* has this information and can provide it to any
other UN*X host on the network.  E.g., when that user tries to
access a remote resource -- like an exported NFS file system!]

When the user is logged onto a Windows host, however, there is
no (uid,gid) to provide to the UN*X host exporting the NFS
file system!  (I have no idea what the terminology is for Windows
credentials... SID's??)

That's where pcnfsd(8) comes in -- it exists to provide a means
whereby remote users can present/validate (UN*X) identifiers which
*it* can map into (uid,gid) credentials *before* accessing the
NFS daemon.  I.e., it really only has to take a user name and
password and map those to a (uid,gid) -- *if* they are "correct".

Then, the remote (Windows, in this case) client can take this
"credential" and contact the NFS daemon AS IF the user was logged
onto a UN*X host.

I *think* all of that can be done without requiring special privilege.

But, pcnfsd(8) is also used as a hook to enable remote access to
printers running on the system that is hosting the pcnfsd.  I.e.,
it allows a Windows user to push data to a printer connected to
(or otherwise served by) the UN*X host.  AS IF the user was logged
onto the UN*X host (again, accomplished by the user name + password
supplied to the protocol) and had submitted the print job locally
(e.g., via lpr(1)).

To do this, pcnfsd has to copy the "data" that is going to be routed
to the printer into a spool directory on behalf of the (remote)
user -- using the (uid,gid) that it has determined as belonging
to that user.  So, it needs to create that directory and a file
belonging to the (uid,gid) for the remote user.  It needs suid
privilege to do this.

But, I *think* that if I don't *use* this (print) capability, I
shouldn't need to run pcnfsd(8) at elevated privilege (?).

I haven't yet dug through the sources to verify that this is,
indeed, the case.  :<  I was hoping to find someone had previously
gone down this road and could offer empirical evidence for that.

[Yes, NFS is a dog -- and a security risk.  As is CIFS.  But, the
machines in question are isolated from all potential threat sources]

Thanks!
--don