well, ok, this is currently mostly about my own language, but I figured it
might be relevant/interesting.
the basic idea is this:
not all code may be from trusted sources.
consider, say, code comes from the internet.
what is a "good" way of enforcing security in such a case?
first obvious thing seems to be to disallow any features which could
directly circumvent security.
say, the code is marked untrusted, and the first things likely to happen
would be to disable access to things like raw pointers and to the C FFI.
the second thing seems to be the option of moving the code to a local
toplevel where its ability to see certain things is severely limited.
both of these pose problems:
simply disabling compiler features may not be sufficient, since there may be
ways of "using" the language which may be insecure and which go beyond
simply enabling/disabling certain features in the compiler.
anything still visible may be tampered with, for example, suppose a global
package is made visible in the new toplevel, and the untrusted code decides
to define functions in a system package, essentially overwriting the
existing functions. this is useful, say, for writing program mods, but may
be a bad things from a security perspective.
a partial option is to give untrusted code its own "shadowed" packages, but
this poses other problems.
similarly, an exposed API function may indirectly give untrusted code
"unexpected levels of power" if it, by default, has unhindered access to the
system, placing additional burden on library code not to perform operations
which may be exploitable.
consider something trivial like:
function getTopVar(name) { return top[name]; }
which, if exposed under a visibility-based security scheme, and the function
was part of a library package (with full system access), now suddenly the
whole security model is dead. essentially it would amount to trying to
create "water tight" code to avoid potential "security leaks".
another security worry is created by, among other things, the semantics of
object delegation (at least in my language), where assigning through a
delegated object may in-turn move up and assign the variable in a
delegated-to object (at the VM level there are multiple assignment operators
to address these different cases, namely which object will have a variable
set in...).
this in-turn compromises the ability to simply use delegation to give each
module its own local toplevel (effectively, the toplevel, and any referenced
scopes, would need to be cloned, so as to avoid them being modified), ...
so, I am left idly wondering:
could a variation of, say, the Unix security model, be applied at the VM
level?
in this case, any running code would have, say, a UID (UserID, more refers
to the origin of the code than to the actual user) and GID (GroupID). VM
objects, variables, and methods, would themselves (often implicitly) have
access rights assigned to them (for example: Read/Write/Execute/Special).
possible advantages:
could be reasonably secure without going through contortions;
lessens the problem of unintended levels of power;
reasonably transparent at the language level (for the most part);
...
disadvantages:
have to implement VM level security checking in many places;
there are many cases where static validation will not work, and where
runtime checks would be needed (possible performance issue);
may add additional memory costs (now, several types of memory objects will
have to remember their owner and access rights, ...);
it could in some cases require funky attributes "$[mode(0xF51),setuid]
public function foo() ...";
...
uncertain:
a means could be provided for a program to request "trust" from the user,
probably in a manner vaguely similar to UAC ("User Access Control") in
Windows, or the digital-signing requests;
if one allows for a system similar to digital signing, there is a potential
risk of forged/stolen keys (effectively requiring user-vigilence), the main
alternative being that the user authorize modules individually if they
require certain features (more similar to installing apps on Android);
...
probable semantics:
declaration permissions (variable/function/class) are likely to be applied
in a manner similar to lexical scoping, where a declaration will retain the
UID in effect at the time of its creation. this will also likely be the case
for functions and methods. this is also likely to be the model employed for
static security checks.
run-time security is likely to follow a model similar to dynamic scoping,
and will likely be applied on a per-thread basis (the current UID and GID
then being a part of the current VM context).
will likely be applied to:
functions/methods, which will mostly themselves care about execute
permissions;
objects, which will care both about access to themselves, and to individual
members.
say, object:
Read, needed to read from any field;
Write, needed to assign to any field;
Execute, needed to call any ordinary method (special cases may require RX).
field/method:
Read, get value from field, get function/method handle;
Write, assign to field, replace/override method;
Execute: call method (N/A for fields);
block/lambda:
Read/Write: N/A
Execute: call lambda.
probably, for now, I will pack all of this into a 32-bit value, say:
12-bits, access flags; 10 bits, owner UID; 10 bits, owner GID.
setuid/setgid would probably be stored with the modifier flags (currently a
64-bit value present in fields/methods/blocks, yes I really do have this
many modifier flags... sadly...).
any thoughts?...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
