All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@myrealbox.com>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: In-kernel Authentication Tokens (PAGs)
Date: Sat, 12 Jun 2004 08:37:32 -0700	[thread overview]
Message-ID: <40CB233C.6050505@myrealbox.com> (raw)
In-Reply-To: <3131BE9C-BC6F-11D8-888F-000393ACC76E@mac.com>

Kyle Moffett wrote:

> On Jun 12, 2004, at 01:34, Andy Lutomirski wrote:
> 
>> Right.  But I think it would be desirable to do other things -- for 
>> example, a program might want to forward one token over to a daemon to 
>> do some work.  It doesn't make much sense here to have a hierarchial 
>> structure.
> 
> 
> So you disagree with the hierarchical structure because you believe that 
> there are other things that are more important that conflict with it.  I 
> see no reason why both cannot be accommodated.  For me, I would really 
> desire a hierarchical structure because it would make it very simple to 
> have a token set for the entire session and one for each instance 
> (shell), and ones for subshells where convenient.

OK.

> 
> You want to sent a token to some daemon over a UNIX socket?  Just copy 
> the token data and write it out to the socket, the same as if you had 
> some external token store (Like in MIT Kerberos) and wanted to send the 
> token to somewhere without the environment variables.  This system would 
> allow several existing token cache mechanisms to be converted to this 
> alternative store without much work at all.

Except I'd like non-root users to have tokens that they _cannot_ read, but 
that they can still pass over unix sockets.  I have no objection to also 
allowing user-readable tokens.

This way I could have a server with, say, a Kerberos service token such 
that a compromise of the server process does not compromise the service 
token.  (You still have a gotcha in that the kerberosd this would require 
would, for performance reasons, want to handle only ticket-granting 
traffic.  Still, you just mark the TGT unreadable and the individual 
session tickets readable, so that the damage of a compromise is limited to 
a few hours until the sessions expire.)

Yes, this would be a _lot_ more work than just blindly porting Kerberos' 
ticket cache, but it has security benefits.

And I really want a good token system in Linux -- that way the OpenAFS 
people will stop bitching and I might be able to use it again.

--Andy

  reply	other threads:[~2004-06-12 15:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-12  2:37 In-kernel Authentication Tokens (PAGs) Kyle Moffett
2004-06-12  3:13 ` Andy Lutomirski
2004-06-12  4:57   ` Kyle Moffett
2004-06-12  5:34     ` Andy Lutomirski
2004-06-12 12:51       ` Kyle Moffett
2004-06-12 15:37         ` Andy Lutomirski [this message]
2004-06-12 17:15           ` Kyle Moffett
2004-06-12  3:15 ` Chris Wright
2004-06-12  4:48   ` Kyle Moffett
2004-06-12 20:53     ` Chris Wright
2004-06-12 21:15       ` Kyle Moffett
2004-06-12 21:44         ` Chris Wright
2004-06-12 21:58           ` Kyle Moffett
2004-06-12 22:51             ` Chris Wright
2004-06-12 23:40               ` Kyle Moffett
2004-06-12 22:51 ` Trond Myklebust
2004-06-12 23:33   ` Kyle Moffett
2004-06-12 23:58     ` Trond Myklebust
2004-06-13  0:23       ` Kyle Moffett
2004-06-15  6:38         ` Blair Strang
2004-06-15  7:03           ` Trond Myklebust
2004-06-15  9:36             ` David Howells
2004-06-15 19:00               ` Kyle Moffett
2004-06-15 22:07                 ` Chris Wright
2004-06-15 23:48                   ` Kyle Moffett
2004-06-16  0:01                     ` Chris Wright
2004-06-16  0:06                       ` Kyle Moffett
2004-06-16 14:22                 ` David Howells
2004-06-15 22:29               ` Chris Wright
2004-06-16 14:37                 ` David Howells
2004-06-15 23:59               ` Kyle Moffett
2004-06-16 14:49                 ` David Howells
2004-06-17  1:13                   ` Kyle Moffett
2004-06-17 11:48                     ` David Howells
2004-06-17 19:06                       ` Kyle Moffett
2004-06-23 12:29                         ` David Howells
2004-06-23 21:03                           ` Kyle Moffett
2004-06-29 17:07                           ` Kyle Moffett
2004-07-07 18:54                             ` John Bucy
2004-07-08  1:29                               ` Kyle Moffett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40CB233C.6050505@myrealbox.com \
    --to=luto@myrealbox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrmacman_g4@mac.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.