[Python-Dev] Re: rexec.py unuseable

[Luke Kenneth Casson Leighton]

On Wed, Dec 17, 2003 at 05:56:37AM -0800, Michael Chermside wrote:
> Luke:
> 
> Seeing as you've now had time enough to read what I'd written, 

 yes i have now, except not yet the link you recommended to 'E',
 which i will get to, soon.


> I was going to 
> respond to some of the points that you made, but then I read Nick Coghlan's 
> posting[1], and I really don't have anything else to add.
> 
> [1] http://mail.python.org/pipermail/python-dev/2003-December/041105.html

 am absorbing that: it looks like a good definition of acls and
 capabilities to me!

> Well, that's not quite true... I guess I _do_ have something small to add.
> In designing a security policy for file systems, there are very few things
> that you can do with the protected items. Separate "read", "write", and
> "execute" permissions seem appropriate. 

 yes.
 
 it's worth pointing out that NT file systems have a lot more than 
 just rwx (which are covered by "generic read" permission, "generic
 write" and "generic execute").

 if i remember correctly, NT file system access permissions also
 include separate permissions for directory access and creation
 that are deliberately distinct from file creation (and maybe
 even file access, too, but it's been a while so i can't be sure).

 they also have "change security descriptor" as a permission.

 ... *click*.

 darn, it.  darn it quite a lot.

 it's been such a long time that i've been confusing "security
 descriptor" with "access control list".  although... thinking
 about it some more i don't think it makes much difference...


 definition of an NT (vax/vms) security descriptor:

	 a security descriptor is a set of "access control lists".

	 there are four ACLs, and they are for different purposes.

	 i can nail down two of them for you: one is a "System"
	 ACL which restricts what the OPERATING SYSTEM can do.
	 another is a "Users" ACL which restricts what _users_
	 can do (and groups, which also under NT have their own
	 identity just like a user has its own identity.)

	there is also some additional information on a per-acl
	basis and it controls the way in which the ACL is used.

 
 ... but all that is by-the-by because, i believe, only _one_
 ACL is needed for the purposes at hand.
 
 anyway, sorry to interrupt the flow, there. :)


> Furthermore, there tends to be a
> clear idea of a "user", and in many situations we want all access to items
> (files) to depend only on who that "user" is (sandboxing an email program
> is an exception... are you listening MS?). Finally, we often want to
> provide centralized administration of access rights to file systems.
> ACLs are a good match for these design specs.

 fully designed, properly designed ACLs are, imo, way over the top for
 file systems, which is why POSIX ACLs are just an extension of
 the standard POSIX filesystem rwx/ugo.

 for NT (and VAX/VMS), the design of the security system came first,
 as a "generic thing", which was then applied to file systems as
 _one_ component, albeit a critical one, of the NT and VMS operating
 systems.

 the NT/VMS security model has room for 32-bits of "permissions" on
 an ACE (access control entry).  16-bit of those are "generic", and
 16-bit of them are "application specific".

 the file-system-specific permissions were created by the writers
 of the NTFS - nt file system - and they gave them life and meaning,
 so to speak, but only in the context of an NTFS and access to it.


> However, controlling what arbitrary programs may do is a very different
> beast. 

 in the context of something like "POSIX ACLs" or in the context of
 something like "POSIX file permissions", yes, absolutely, i agree
 with you entirely.

 in the context of something as flexible as NT/VMS security descriptors,
 no, i don't agree, because NT SDs are very generic and had to be
 "specialised" to fit onto the NTFS.

 which implies that something as flexible as NT/VMS SDs could equally
 and as easily be adapted to fit controlling what arbitrary programs
 do.

 _and_, in the NT operating system and its core [mostly user-space]
 components, this _has_ already been done [and i presume likewise
 in VMS].

 for example, there is a spoolss (printer service) and there is a
 SAM (security accounts manager) database service.

 the authors / designers of these two services created their own
 set of 16-bit application-specific permissions, gave them life
 and meaning in the context of their individual services, and made
 sure that each function _in_ that service double-checked the
 permissions against the type of operation that that function
 performed.

 to give you an example, this is some pseudo-code of the SamrCreateUser
 function:

 static SEC_DES[] sec_des_array = {
	 ...
	 ...
	 samr_create_user_security_descriptor,
	 ...
 };

 STATUS32 SamrCreateUser(pHND *context, UNICODE_STRING *username)
 {
 	USER_TOK *user = GetUserToken(context);
	if (!check_security_descriptor(user, context, SECDES_SAM_CREATE_USER))
	{
		return NT_STATUS_ACCESS_DENIED;
	}
	....
	....
 }

 the context handle stores references to quite a bit of state
 information about the connection (it's a DCE/RPC thing).

 the SECDES_SAM_CREATE_USER permission is an application-specific bit
 that is specifically and only used to check access permission to
 the SamrCreateUser function.


> First of all, the kinds of restrictions that we want are HIGHLY
> variable. Sometimes we want to prohibit all file access. Sometimes we
> want to allow read-only access to a certain file only. Sometimes we
> want access only to a certain directory. Sometimes we don't care at
> all about file system access, we're concerned instead with providing
> an object which can be queried but only in certain ways -- and the
> specifics of what is permitted and what isn't are completely dependent
> on the particular application.
> 
> On top of that, there's rarely a clear concept of "users" that controls
> what actions we want to permit. Instead, we usually want to allow or
> deny certain capabilities to particular _sections of code_. (Sometimes
> that will be a module, sometimes a plug-in, sometimes a child program.)

 yes.

 and i believe that the

> All of these things suggest that maintaining a list of who 

 [or rather "what" - i.e. "Entities", yes?]

> is permitted
> to access what is simply not the best model for providing security in
> a programming language. 

 i am curious: how does that logically follow?

 in my experience (windows nt services and therefore also samba-tng's
 services), access control lists have been an extremely successful
 means to provide security in almost every single program in the
 NT operating system (i don't mean XP i don't mean windows 95) for
 almost 15 to 20 years.

 it seems quite logical therefore to propose that such a successful
 security model be adapted to fit a programming language, or at least
 to learn from its success (and failings).



 change of subject
 -----------------
 
 i believe that it _is_ possible to express what nick coghlan
 defines capabilities to be _into_ an ACL.

 how?

 by creating a security permission called "can you see it and execute it?"
 let's call it SEE_AND_EXECUTE

 then, the language (interpreter) does this (following the example of the
 SamrCreateUser function, above):

 MakeFunctionCall(Context *stack, CodeObject *code)
 {
 	char *callee_fn_name = GetCalleeName(stack);
	SEC_DES *sd = GetSecurityDescriptorForCode(code);

	/* check the capability to even _see_ this function! */
	if (!check_sec_des(sd, callee_fn_name, SEE_AND_EXECUTE))
	{
		return Exception("Function name %s does not exist",
		                 code->function_name);
	}

	/* okay, they can see it [and execute it] */

    ....
	....

 }

 does that make sense at all?

 l.