On 8/12/2011 9:23 AM, David Barbour wrote:
On Fri, Aug 12, 2011 at 2:44 AM, BGB <cr88...@gmail.com
<mailto:cr88...@gmail.com>> wrote:
but, whether or not they use it, or care that it exists, is
irrelevant...
Then so is the language.
by this criteria, pretty much everything is irrelevant.
my concept of relevance is structured differently, and is not based
either on authority or gaining authority over others' choice of which
languages/software/... to use, but rather on the ability of a piece of
software/... to be used to complete tasks.
in this sense, my stuff thus has some relevance (to myself) because I
make use of it.
this would be because relevance is a property essentially subject to
each individual, their relations to things, and their relations to
others, ...
but, anyways, FWIW, I am myself a part of the audience of people
who would use my language, so I am free to design it how I want it
designed, which happens to largely coincide with common practices.
A language is a very large investment, as you are aware. You say
'FWIW' (for what it's worth), but how much is your language worth,
really? How much time and effort have you wasted on your language that
would have been better spent maintaining a project in an existing
language?
most of my projects' codebase is actually in C, but there is a lot of
"shared architecture" as well.
in around 2007-2010 I had largely almost forgotten about the existence
of my language, but it gained more weight with myself once some random
changes (elsewhere in the VM subsystem) caused it to become less lame...
2007 was mostly first spent with me trying to migrate my scripting to
dynamically-compiled C code, but this wasn't really working out.
2008-2010 was mostly me looking at trying to migrate my efforts to Java,
but despite my efforts, I couldn't make Java into something I wanted to
use (and using JNI is a big pile of suck...).
also, because in the areas I care about, it does a better job than V8 or
SpiderMonkey...
also, because unlike Python or Lua, it doesn't seem "totally weird"...
also, because it builds on the same infrastructure as most of the rest
of my code, so it is the "path of least resistance";
...
like, say, one has an issue:
they can, either, go fix it in their own code;
or abandon their code and try to switch over to a different piece of
technology.
which is less work?...
typically, fixing a bug or adding a feature is relatively little effort
(minutes or maybe hours).
switching out to a different piece of VM technology may be a much huger
investment, potentially requiring days or weeks of effort, or more (say,
requiring a large scale rewrite of their project from the ground up),
and having to climb the learning-curve treadmill (like, for example,
familiarizing oneself with all of the Python APIs or similar, ...).
but, security checks seem like less up-front effort to bolt on to
the VM...
The investment is about the same.
investment == ease of use + implementation costs.
the overall cost of capabilities would seem to be a little higher.
it would be along the lines of:
"well, I am just going to write this big pile of stuff really quick and
dirty which looks like it escaped from C" followed by "oh crap, it
doesn't work...".
whereas, with privilege checks, it will work if it is running as "root",
or throw an exception otherwise.
now, the question becomes, what about security (assuming the whole
system is designed well) and performance? capabilities could potentially
be better on this front.
also, security-check models are well proven in systems like Windows and
Linux...
for example, in Linux, a plain user over SSH tries to execute "shutdown
-h 0", but it fails to do anything. this is because, it is a matter of
rights (via a check), and not because "shutdown" is nowhere in the path
(depends some on distro though, as some distros tend to leave "/bin" and
"/sbin" out of ordinary user paths, forcing them to fully qualify the
path for system tools after doing an "su root").
however, the ability of a user to type "/sbin/shutdown" does not
compromise the system.
it is not clear that users can so easily ignore the existence of a
capability-oriented system.
Capability based security is quite transparent to most users. To those
unaware of the security implications, it just looks like a very well
designed API - one suitable for concurrent or distributed computing or
testing, or flexible composition (e.g. ability to wrap access to the
'console', or have different 'consoles' for different libraries).
I mean, transparent in the sense that it looks just like code without
it, namely:
a big global namespace and ability to declare and import packages
wherever, ...
not that it is really "one or the other" though, as my current planned
strategy actually consists of making use of *both* sets of strategies
(in a sort of half-assed way).
like, use whichever is less effort at each point in the process...
also, the toplevel is very convinient when entering code
interactively from the console, or for use with "target_eval"
entities in my 3D engine (when triggered by something, they
evaluate an expression), ...
A toplevel, or other forms of dynamic scope, is not incompatible with
capabilities, so long as you can re-assign it for different scopes and
threads. It is incompatible with secure interaction design, but that's
a separate issue.
fair enough. my implementation includes the ability to assign toplevels
per-thread, and also per-code region (via the "withtop()" statement).
however, I was also considering doing per-UID toplevels.
this would be because unlike with individually constructing toplevels, a
per-UID toplevel makes it a little more straightforward to reuse toplevels.
hmm... but then again, the above does essentially blur the line
separating a UID from what is more like a PID. meanwhile, GID seems
redundant. I could change the model to be UID+PID instead, with PID
selecting between toplevels.
but then UID/PID relation would seem to differ somewhat from the UID/GID
relation, unless I simply drop the concept of GID from the model
(UID-based checking only, or with GID implicit and existing on a per-UID
basis, hmm...).
grr...
my own imagined methodology was likely to make use of program
signatures (file hashes for the programs' image file), with user
confirmation as to whether or not they want to give certain rights
to an app. this would be because it is a little harder to forge a
file hash than it is to capture things like "magic keys" or
"passphrases".
That sounds complicated, and I doubt your users will benefit from it.
well, it works though, and a lot of people still use Windows...
Pushing blame to users is not effective for security. People suffer
malware on a regular basis. IT administrators feel the need to strip a
user's rights to their machines, which really chafes for programmers.
People feel need to bloat their systems with anti-virus software and
computer 'defenders'.
Whether 'it works' depends on your goals: are you actually interested
in security? or are you just trying to avoid blame?
in a strict sense, it is not clear that there is all that much
difference given many of the system architectures I have seen (both
Windows and Mozilla often seem to go this route, ...).
A lot of people still use Windows, but only a fool would mistake a
popularity argument for a security argument.
the problem though would be that many users don't really know what they
are doing (back to the "stupid users" issue).
better though I think is the idea of somewhat lessening the base-power
given to the apps, while still leaving them fairly capable of doing
their own stuff (for example, an app can provide a UI, ..., but
shouldn't have access to the users' files or ability to change any of
their settings unless specifically allowed). for example, just because a
user has the right to change their homepage or desktop background,
doesn't mean that any app they run should be able to do similar.
for example, typical Windows apps have roughly the same rights as the
user accounts which use them, which although this doesn't necessarily
compromise the system, the default "user privileges" are still plenty
powerful WRT doing a lot of damage.
it would appear that in newer Windows (Win7), each level got moved
downwards (vs WinXP):
"Administrators" is now more like "Normal User" in WinXP, but with the
ability to elevate the rights of certain apps/... (to be able to do
things more like Administrator in XP);
"Normal User" now seems more like the older "Guest User".
ideally, IMO, the user retains roughly the same level of security as
before, but applications run under their own virtual users with
considerably less rights.
newer Linux distros also seem to do similar to Windows, by default
running everything under a default user account, but requiring
authorization to elevate the rights of applications (to root), although
albeit with considerably more retyping of passwords...
object is not writable: why?... because we don't have write access...
otherwise, one would need to use a "readonly" modifier or similar,
but this would apply to everyone, rather than be like "well, I can
use this read/write, but everyone else gets it as read-only".
The capability approach to this would be to create a separate readonly
object:
var myObjReadOnly = WriteBarrier(myObj)
Now, everyone who has access to 'myObj' can still write it, and
everyone who as access to 'myObjReadOnly' can only read it.
Potentially, the WriteBarrier could also apply to all objects returned
from method calls or accessors - this is a 'membrane'
pattern. WriteBarrier doesn't need to be special. It can be
implemented with a much more generic feature that allows developers to
override the 'getter' and 'setter' functions for an object.
oh, holy crap, I didn't think of this...
this is potentially a very nifty idea...
granted, to do this as a generic object would likely require a setter
something like:
"public function set _(val) { return(undefined); }"
with "get _()" and "set _()" basically meaning get/set any functions
(where "any" is checked assuming that no other matching field or
property is found...).
a little syntax hack could also allow "get*()" and "set*()"...
also possible would be just to throw a generic "barrier" object type
into the mix, which could have flags as to whether or not to filter
certain types of actions (could also block reads and method calls, or
block a certain list of names, or only allow a certain list of names, ...).
var newTopBarrier=createBarrier(top, #readOnly, blacklist: [#ctop, #bsvm]);
var newTop={#topchain: newTopBarrier}; //empty object which delegates
to toplevel
withtop(newTop) //run as new toplevel
{
...
}
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
