Re: MEMORY credential cache interop between Heimdal and MIT?

[Michael B Allen <miallen@ioplex.com>]

On Wed, 29 Aug 2007 09:46:43 -0700
Howard Chu <hyc@highlandsun.com> wrote:

> Hi Mike,
> 
> Michael B Allen wrote:
> > Hi Howard,
> > 
> > Actually I've changed my mind (somewhat). I think I will pursue the mmap
> > descriptor inheritance technique. It seems like it could be elegant,
> > portable and it would satisfy my immediate web server problem and the
> > implementation interop issue. For some reason I didn't think descriptors
> > would be inherited across execv but after trying a few tests I am
> > satisfied that the technique could be quite effective.
> > 
> > However, without a file access point it cannot be used in place of a
> > regular ccache file.
> 
> I don't understand this statement. All you need is the descriptor to access it. 
> (So yes, you need a valid file to begin with, you cannot just use an anonymous 
> mmap. But you can create the file with mode 000 and unlink it immediately, to 
> prevent anyone else from opening it.)

That's not what I meant. A disk file can be opened by anyone with
appropriate permissions. In the web server scenario this has an
"ownership issue" which is described below.

But it escaped me that MAP_ANON cannot be used since there needs to be
a file descriptor to inherit. So yes, I suppose I will have to use the
technique you describe above. No problem.

>  > And with it it has the same ownership issue as a
> > regular ccache file. Also, access control is limited to what inheritance
> > provides.
> 
> Could you summarize these ownership concerns again, or point me at an archived 
> posting that enumerates these issues? I've missed some context somewhere.

The "web server scenario" is as follows:

A web server running workers as user 'httpd' accepts a Kerberos TGT using
GSSAPI and wants to make it available to Kerberos aware client libraries
such as pgsql_connect, curl_open or ldap_sasl_bind. Using currently
available methods the only way to do this is to put the TGT into a regular
ccache file and set KRB5CCNAME to it's path. After calling the library
routine the ccache file is destroyed. However, there is a problem. Because
the ccache file is owned by 'httpd', anyone with permission to run scripts
on the web server can scan the directory in which ccache files are stored,
export KRB5CCNAME and use the credential to impersonate the user.

> > Locking issues can be handled
> > much more effectively (e.g. no orphaned semids). The kernel has
> > the best vantage point to protect sensitive data like credentials.
> 
> SysV IPC is not a good solution here. (or just about anywhere, for that 
> matter...) Use sem_init() and store the semaphore in the mmap'd memory region.

With respect to the descriptor inheritance idea there are a variety
of factors that could affect locking. Does the storage need to be
MMAP_SHARED? I'm thinking "no" in which case there's no need to place
a semaphore in the mmap'd region at all. If the storage does need to be
shared between processes then that might be a problem since I think there
are still some systems that do not support process-shared semaphores.

> IMO, any kernel extension must still obey standard Unix security semantics. 
> I.e., it allows resources to be opened based on mode bits, and allows access to 
> any process that already has the open descriptor.

The idea was to make the device 0666. Anyone can open it. But they will
not be able to read or write it until they do the ioctl. The ioctl
iterates over a list of storages that have certain attributes. The
attributes are compared with the calling processes (or whatever other
information that storage's access control method requires) to determine if
that process is granted access to that storage. If no suitable storage is
found, a new empty one is created, programmed with the desired criteria
and the ioctl returns success.

Mike

-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/