On Thu, Aug 11, 2011 at 5:06 PM, BGB <cr88...@gmail.com> wrote:
>
> the big problem though:
> to try to implement this as a sole security model, and expecting it to be
> effective, would likely impact language design and programming strategy, and
> possibly lead to a fair amount of effort WRT "hole plugging" in an existing
> project.
>
A problem with language design is only a "big problem" if a lot of projects
are using the language. Security is a big problem today because a lot of
projects use languages that were not designed with effective security as a
requirement.
>
> how to effectively prevent spoofing (say, one manages to "extract" the key
> from a trusted app, and then signs a piece of malware with it).
>
Reason about security *inductively*. Assume the piece holding the key is
secure up to its API. If you start with assumptions like: "well, let's
assume the malware has backdoor access to your keys and such", you're
assuming insecurity - you'll never reach security from there.
Phrases such as 'trusted app' or 'trusted code' smell like vaguely of
brimstone - like a road built of good intentions. What is the app trusted
with? How do we answer this question with a suitably fine-grained executable
policy?
>
> yes, there is still always the risk of a naive user confirming a piece of
> malware, but this is their own problem at this point.
>
I disagree. Computer security includes concerns such as limiting and
recovering from damage, and awareness. And just 'passing the blame' to the
user is a rather poor justification for computer security.
>
> if trying to use a feature simply makes code using it invalid ("sorry, I
> can't let you do that"), this works.
>
When I first got into language design, I thought as you did. Then I
realized:
* With optional features, I have 2^N languages no matter how I implement
them.
* I pay implementation, maintenance, debugging, documentation, and design
costs for those features, along with different subsets of them.
* Library developers are motivated to write for the Least Common Denominator
(LCD) language anyway, for reusable code.
* Library developers can (and will) create frameworks, interpreters, EDSLs
to support more features above the LCD.
* Therefore, it is wasteful to spend my time on anything but the LCD
features, and make life as cozy as possible for library developers and their
EDSLs.
*The only cogent purpose of general purpose language design is to raise the
LCD.*
Optional features are a waste of time and effort, BGB - yours, and of
everyone who as a result submits a bug report or wades through the
documentation.
>
> with a language/VM existing for approx 8 years and with ~ 540 opcodes, ...
> I guess things like this are inevitable.
>
I think this is a property of your language design philosophy, rather than
inherent to language development.
> but whitelisting is potentially much more effort than blacklisting, even if
> potentially somewhat better from a security perspective.
>
Effectiveness for effort, whitelisting is typically far better than
blacklisting. In most cases, it is less effort. Always, it is far easier to
reason about. I think you'll need to stretch to find rare counter-examples.
> LambdaMoo found a MUD, if this is what was in question...
>
LambdaMoo is a user-programmable MUD, with prototype based objects and a
Unix-like security model.
> as for "simple" or "efficient", a Unix-style security model doesn't look
> all that bad.
>
Unix security model is complicated, inefficient, and ineffective compared to
object capability model. But I agree that you could do worse.
>
> luckily, there are only a relatively small number of places I really need
> to put in security checks (mostly in the object system and similar). most of
> the rest of the typesystem or VM doesn't really need them.
>
I recommend you pursue control of the toplevel capabilities (FFI, and
explicit forwarding of math, etc.) as you demonstrated earlier, perhaps add
some support for 'freezing' objects to block implicit delegation of
assignment, and simply forget about Unix or permissions checks.
Regards,
David
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
