Subject: New SFTP extension: enable privileges on the server...

From: Joseph Galbraith <[email-masked]>
Date: Tue, 30 Aug 2005 08:37:02 -0600

In some operating systems (Windows NT, VMS I think, not sure
about the big mainframe OSes), a user can have the right to
certain privileges, but most explicitly activate the privilege
in order to use it.

Two such privilege under Windows NT are the Backup privilege
and the Restore privilege.

In order to make SFTP a more useful protocol, I propose
adding the following extension:

        byte    SSH_FXP_EXTENDED
        uint32  request-id
        string  "enable-privilege" / "disable-privilege"
        boolean require-all
        string  priv-list[]

priv-list strings are either implementation dependent,
or from the following list.

MS privileges as defined in the PSDK:

   [email-masked]

Standard privileges:
   BACKUP@
     Right to read any file or directory, bypassing
     read access control checks.

   RESTORE@
     Right to create / write any file or directory,
     bypassing access control checks.

I'm not sure if there are any other privileges that
should be standard?

If the server doesn't support a given privilege,
the user implicitly doesn't have the right to
enable it.

If 'require-all' flag is specified and any of the
privileges could not be enabled, or if none of the
privileges could not be enabled, the server MUST
disable an privileges that were enabled and send
an appropriate error code.  (SSH_FX_PERMISSION_DENIED
if the user doesn't have the right to enable
the requested privileges.)

If the 'require-all' flag is not set, and some
of the privileges were enabled, the server
responds with:

        byte   SSH_FXP_EXTENDED_REPLY
        uint32 request-id
        string enabled-privileges[]

Because of it's security sensitive nature, implementations
SHOULD provide a site specific means of enabling or
disabling it.  It SHOULD be disabled by default.

What do people think?  If I need to I can do this
one as a @vandyke.com if / when we get ready to
support it.

Thanks,

Joseph

---

From: Darren J Moffat <[email-masked]>
Date: Tue, 30 Aug 2005 15:50:13 +0100

> certain privileges, but most explicitly activate the privilege

(Open)Solaris and Trusted Solaris have privileges and authorisations.
Users have authorisations.  Processes have privileges.  In Solaris
a process can manipulate its privileges and privileged processes
check authorisations.  Lets take a hypothetical example:  We
have a backup program that only certain users are allowed to use,
the backup process uses privileges to read/write files it wouldn't
otherwise be able to.  That same backup program checks authorisations
to ensure that only the correct subset of users can perform restores.

> and the Restore privilege.

In Solaris processes have privileges - this is the breakup
of the all powerful root.  A process has a number of different
privilege sets:
	E - Effective Set: What I'm using now.
	P - Permitted Set: Max I can use.
	I - Inheritable Set: What I give to children.
	L - Limit Set: Max children can get.

Given that I think your packet needs a place to specify
the privilege set as well for this to be useful on Solaris.  We
could assume the effective set is what you wanted to manipulate
since it sounds like that matches your Windows view, but it would
be better to allow it to be explicit.

>      read access control checks.

Sounds like file_dac_read in Solaris.

>      bypassing access control checks.

Sounds like file_dac_write for Solaris.

I sounds an interesting proposal.  My major question though is
what is the expected behaviour if a Windows client connects
to a Solaris server and asks for BACKUP@ to be enabled ?  Are
we supposed to map this to file_dac_read ?  What if it is the
other way around ?

-- 
Darren J Moffat 
TZ=Europe/Dublin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Aug 2005 13:28:48 -0400

> be better to allow it to be explicit.

I don't think so.  In the context of sftp, the only interesting set of 
privileges are those actually used to perform operations on behalf of the 
user.  Exactly which set is relevant is going to vary depending on the 
operation in question and how it is implemented (for example, the server 
might decide to do some operations in a subprocess).  The client has no 
business knowing whether the sftp server has children or what privileges 
they might have.

Similarly, just because the client says "enable this privilege" doesn't 
mean the entire sftp server needs to run with that privilege all the time. 
It would be entirely reasonable for an implementation to enable them only 
when accessing files on the user's behalf.

I would suggest adding an operation to fetch the current set of privileges 
and/or the set of all permitted privileges.  The latter would have to be 
computed by the server based on what privileges are actually permitted to 
it, what it needs to perform various operations, and local policy.  For 
example, an sftp server might run with privileges which it is not willing 
to make available to the user.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA