[Python-Dev] Re: rexec.py unuseable (original) (raw)

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Dec 17 14:06:52 EST 2003

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.

More information about the Python-Dev mailing list