All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: David Howells <dhowells@redhat.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	openafs-devel@openafs.org
Subject: Alternative to PAGs
Date: Thu, 15 May 2003 15:15:49 +0100	[thread overview]
Message-ID: <6624.1053008149@warthog.warthog> (raw)


Hi Linus,

Okay, starting with a clean slate and writing PAGs off as a bad idea, how
about trying to work out what is required first? As I see it:

THE REQUIREMENTS
================

  (1) Credentials/tokens/keys/whatever are held in a "keyring".

  (2) A keyring is destroyed when the last reference goes away (kernel
      resources are precious, though it may be possible to store credentials
      in swapspace somehow).

  (3) Every user has to have a default keyring that is created the first time
      they log in [Linus demands this].

  (4) A user has to be able to override the default keyring, such that they
      can, for instance, perform operations on a remote filesystem with a
      different credential.

  (5) A user has to be able to run a program with a reduced set of
      credentials.

  (6) A process must be able to pass a subset of its credentials to a second,
      already running process so that the second process can perform some
      service on its behalf.

      This gets tricky if the service process is performing services for a
      number of processes simultaneously, each of which has its own set of
      credentials.

  (7) A process should be able to discard any credential it has access to,
      particularly in conjunction with (6).

  (8) It must be possible to withdraw a credential.

  (9) The credentials governing access to a file must be associated with a
      struct file, not with the process context currently accessing a file.

 (10) A struct file will gain its credentials at the time it is opened.


POSSIBLE EXTENSIONS
===================

 (11) Threads should perhaps share a common set of credentials, but be able to
      adjust them on a per-thread basis (see (6)).

 (12) A SUID process should add the credentials it gains from its new user ID
      to those it inherited from its original context.

 (13) There's one place Win32 has an advantage, I think: calls for setting up
      handles (files, mutexes, etc) take security context parameters.


I think "groups" specific keyrings and arbitrary joinable keyrings are
superfluous (that's what ACLs are for) and a systems maintenance nightmare, so
I haven't included them.


SUGGESTED IMPLEMENTATION
========================

As far as implementation goes, perhaps each task_struct and each file should
point to a stack of keyrings:


                                         +------+
                                         |      |
                  +--------------------->| USER |
                  |                      |      |
                  |                      +------+
                  |
 +------+      +------+     +------+     +------+
 |      |      |      |     |      |     |      |
 | TASK |----->| SUID |---->| PRIV |---->| USER |
 |      |      |      |     |      |     |      |
 +------+      +------+     +------+     +------+
                  ^            ^
 +------+         |            |
 |      |         |            |
 | FILE |---------+            |
 |      |                      |
 +------+                      |
                               |
 +------+                      |
 |      |                      |
 | FILE |----------------------+
 |      |         ^
 +------+         |
                  |
 +------+      +------+                  +------+
 |      |      |      |     		 |      |
 | TASK |----->| FILE |----------------->| USER |
 |      |      |      |     		 |      |
 +------+      +------+     		 +------+     

The keyrings in the stack would then be refcounted, and the next pointers
would be immutable.

	struct keyring {
		struct keyring		*next;
		struct keyring		*conjunction;
		struct list_head	keys;
		atomic_t		usage;
		int			type;
	#define KEYRING_USER	0
	#define KEYRING_PRIVATE	1
	#define KEYRING_SUID	2
	#define KEYRING_FD	3
	};

	struct key {
		struct list_head	link;
		atomic_t		usage;
		int			type;
	#define KEY_POSITIVE 0
	#define KEY_NEGATIVE 1
		void			*credential;
	};

And then add the following syscalls:

 (*) auth_clear_stack(int completely)

     Totally clear a process's stack (either completely or of everything but
     the user credentials).

 (*) auth_add_cred(const char *fs, const char *domain, void *data);

     Add a new credential to the TOS keyring. The key would be negative if
     data is NULL.

 (*) auth_push_empty()

     Push an empty keyring onto this process's stack.

 (*) auth_push_fdcreds(int fd)

     Push the credentials associated with fd onto the stack as a preferred
     alternative.

 (*) auth_pop()

     Pop the top credential off of the stack.


David

             reply	other threads:[~2003-05-15 14:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15 14:15 David Howells [this message]
2003-05-15 16:53 ` Alternative to PAGs Linus Torvalds
2003-05-15 23:14   ` [OpenAFS-devel] " Garance A Drosihn
2003-05-15 23:14     ` Garance A Drosihn
2003-05-16  0:46     ` [OpenAFS-devel] " Russ Allbery
2003-05-16  0:46       ` Russ Allbery
2003-05-16  0:43   ` [OpenAFS-devel] " Garance A Drosihn
2003-05-16  0:43     ` Garance A Drosihn
2003-05-16  0:56     ` [OpenAFS-devel] " Nathan Neulinger
2003-05-16  0:56       ` Nathan Neulinger
2003-05-16 11:08   ` David Howells

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=6624.1053008149@warthog.warthog \
    --to=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openafs-devel@openafs.org \
    --cc=torvalds@transmeta.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.