[Python-Dev] Re: rexec.py unuseable
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