Re: [9fans] Inferno plug-in security

Re: [9fans] Inferno plug-in security

[rog]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

yes, that's a possible type of approach, but i detect a certain amount
of handwaving in your description...  restricting the accessible
directories, or even read/write access to them, is probably not
sufficient. (it couldn't give you selective access to different IP
addresses, for example).

and there still remains the question of how to deal with module signing
(which is necessary, in some form, even if you've got verified Dis, to
prevent a module from creating its own Dis module (unverified) and
calling that).

as i said before, there are some difficult security issues that need to
be resolved before we do it, none of which have obvious solutions.

  cheers,
    rog.


[-- Attachment #2: Type: message/rfc822, Size: 2555 bytes --]

To: <cse.psu.edu!9fans>
Subject: [9fans] Inferno plug-in security
Date: Fri, 15 Jun 2001 14:47:38 +0300
Message-ID: <EE9F3A089F0B01499C5782E7CFA9352708B76E@hkisrv08.teleware.fi>

> like: what happens if someone puts a limbo app on a web page that
takes
> up no screen space, but dials out and does nefarious things (e.g.
> taking part in a DDOS attack).

Why don't you just give the plug-in user a simple configuration
interface to control what directories the plug in is allowed to access,
and in what ways (read/write/etc..)? This configuration could work
dynamically and popped up when non-existing directories are trying to be
opened during the execution of the plug-in.

Any file system "object" which is too liberal in its standard form can
be "stacked by"/"inherited to" a new restricted/augmented/modified
version. A selection of these can be provided with the plug-in,
programmed by the user, or done by a third party, maybe mounted from
elsewhere in the network.

Re: [9fans] Inferno plug-in security

[David Gordon Hogan]

> from my own observations and from a well know security presence, the bottom line is:
> 
>     this is no security

This ain't no party
This ain't no disco
This ain't no fooling around

Re: [9fans] Inferno plug-in security

[Boyd Roberts]

> so you tell :-)

> SFR, Paris, France
> End to end security study of HDML [WAP]

yeah and soon i'll be able to tell the coolest/stupidist SFR screwup which involved
security, but i have to re-read my contract.

> France 3, Paris, France
> Design and development of client/server applications 
> Design and installation of Firewall (SV5R4).

yep when we used to build 'em by hand.

i could tell you a story about gatekeeper.dec.com, when i was digital employee,
but a reliable source tells me that i should keep that to myself.

> skills used : Cryptography, C, IP , IP Security 

yeah that got used.  i can tell you that alphas, DES and a chunk of disks were used.

> surely that's just restating the problem?

but that _is_ the problem.  it's very simple.  doing it right is the hard part.

doug gywn is an infinitely better crypto source than i am.

from my own observations and from a well know security presence, the bottom line is:

    this is no security

no one cares.

Re: [9fans] Inferno plug-in security

[Matt]

----- Original Message ----- 
From: "Boyd Roberts" 


> > You've got lots of security experience
> 
> so i am told.

so you tell :-)
SFR, Paris, France
End to end security study of HDML
skills used : Cryptography, C, IP , IP Security 

France 3, Paris, France
Design and development of client/server applications 
Design and installation of Firewall (SV5R4).
skills used : Cryptography, C, IP , IP Security 

> anyway, you can break it down to two rules:
> 
>     - what have you got to protect
>     - how much are you prepared to spend
> 
> and those two can be managed in interesting ways.

surely that's just restating the problem?

Re: [9fans] Inferno plug-in security

[Boyd Roberts]

> You've got lots of security experience

so i am told.

but it's always a trade-off -- what you want to protect and how much you're prepared
to spend/invest to protect it.  every situation is different.  it even comes down to how
long the information is valid for.

guess the base level premise is:

    - you don't want to get ripped off [authentication]
    - they don't want to get ripped off [authentication]
    - the transaction has to happen in such a way -- ahh, non-repudiation is the word

[my english/french is in a bit of a weird state after the london trip, but it's pretty
much like that most of the time now]

anyway, you can break it down to two rules:

    - what have you got to protect
    - how much are you prepared to spend

and those two can be managed in interesting ways.

Re: [9fans] Inferno plug-in security

[Matt]

----- Original Message -----
From: "Boyd Roberts"
Sent: Friday, June 29, 2001 10:57 PM
Subject: Re: [9fans] Inferno plug-in security


> > security consists of (at least?) two parts: authentication (who am i)
and
> > authorization (what can i do).
>
> err well, you have to authenticate the thing you are talking to, so
there's
> another piece that has to be done right.

but what's your overall opinion on how it should be done Boyd?

You've got lots of security experience

Re: [9fans] Inferno plug-in security

[Boyd Roberts]

> security consists of (at least?) two parts: authentication (who am i) and
> authorization (what can i do). 

err well, you have to authenticate the thing you are talking to, so there's
another piece that has to be done right.

Re: [9fans] Inferno plug-in security

[Rome Huang]

I think before a secure way emerged, Vita should release a middle version
with a restricted networking capability, maybe restrict access to download
site only.

~Rome.

Re: [9fans] Inferno plug-in security

[anothy]

anssi wrote:
//Certainly, you are right.

oh, good.

//But the first and easy step for Inferno plug-in security is to let the Web
//browser user decide, what "objects" are bound to the name space.

i guess. i don't relly have any opinion as to which is more important or
should be there first, authentiction or authorization. it doesn't seem like
building a namespace defined per-module is really useful without reliably
knowing who that module is. well, there's always a default case, but as i
said earlier, that either ends up being too restrictive or too permissive.

still, you are correct in that the 'build a namespace' part of the problem is
an effective way to address the authorization issue, is a needed step, and
is probably more easialy solved.

eric wrote:
//...you are addressing a situation like a web page which may have all
//kinds of unknown modules...

yes, that's one example. but even a web page with one module has the
same issues behind it.

//...then i don't believe that signing is security. just because the module
//came from microsoft and was signed with the super-private microsoft
//key, doesn't mean that the module doesn't do things that you don't allow.

oh, more acuratly, if it came from microsoft, it probably means it _does_
do things i don't like. ☺ but sure, we don't want to allow _any_ module
signed by _anyone_ to do _anything_, just because it's signed. but i
probably trust modules written by me to do pretty much anything - make
network connections, write to my display, access local files, whatever.
same with modules written by VN, the Labs, or a few other individuals. on
the other hand, i probably don't trust modules from M$ or people i've
never heard of to do much - say, no network connections, no looking at
local files. in order to tell which permissions to use - which sandbox to
construct - i need to know who i'm dealing with.

of cource, this is much harder than simply defining a restrictive sandbox
for all modules to play in (which is basically what we've got now). maybe
a simpler alternative would be that when loading a module, a box pops up
with a series of check boxes for things like "make network connections"
and "access local files", determining what this module can do? simpler
than the user constructing a custom namespace for each module.
-α.

Re: [9fans] Inferno plug-in security

[Matt]

> But in Inferno/Plan 9 you can have an exact control on a set of
> resources an untrusted module is allowed to access. Not a sandbox, but a
> custom built playing field bildable with "bind -a"

defaulting to what we have now, so scrollers and the like don't "bother" you
asking for permission to access the display.


Well, that's that solved ;)

just the backspace key to go now

M

Re: [9fans] Inferno plug-in security

[Anssi Porttikivi]

<anothy@cosym.net> wrote in message
news:<20010619171302.3531519A05@mail.cse.psu.edu>...
> //the basic idea in all Plan 9 and Inferno is, that even network
connections
> //are services offered by directories which are called "file systems"
> 
...
>different users have different permissions to different
> things, right? we can tell these users are different people because
they have a
> certain key/passwd/response. without signing on a dis module, we face
two
> problems, both of which exist in any system with no authentication...

Certainly, you are right. But the first and easy step for Inferno
plug-in security is to let the Web browser user decide, what "objects"
are bound to the name space. Implementing or installing a good selection
of inheritance hierarchy of "directory objects" the user can choose at
will, and interactively, at the precision of his liking, what the
plug-in is EXACTLY allowed to do.

Besides, it would be fairly easy to allow the user to configure
different Inferno user id's and choose, which identity a plug-in is
allowed to use. Of course there will be a further, advanced need for
module signing. That is why module signning was designed to be part of
Inferno. But in Inferno/Plan 9 you can have an exact control on a set of
resources an untrusted module is allowed to access. Not a sandbox, but a
custom built playing field bildable with "bind -a"

Re: [9fans] Inferno plug-in security

[erik quanstrom]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

if i understand, you are addressing a situation like
a web page which may have all kinds of unknown modules,
etc.

if that is the case, then i don't believe that signing is
security. just because the module came from microsoft and
was signed with the super-private microsoft key, doesn't
mean that the module doesn't do things that you don't allow.
hey, the key could have been stolen (what would be the chances ;-)
or it might just be buggy (what would be the chances).

i think that you are going to have to run dis modules loaded
in a situation like a web browser into a sandbox that has
very restricted premissions in order to avoid security issues.
in that case, there's not much point to all the complication
of signing.

erik

----------------

//the basic idea in all Plan 9 and Inferno is, that even network connections
//are services offered by directories which are called "file systems"

you're correct, of cource. but think about it in terms of a normal file system,
like local disk or such. different users have different permissions to different
things, right? we can tell these users are different people because they have a
certain key/passwd/response. without signing on a dis module, we face two
problems, both of which exist in any system with no authentication. first,
when someone does something we don't like, we don't know who to blame.
if someone's doing things i don't like on my system, i want to know about it.
similarly, if i load a dis module that does things i don't like, i want to know
who wrote it and/or who gave it to me. second, without any reasonable
method of telling who's who, if i want to restrict _someone_ from doing
something, i have to restrict _everyone_. if, for example, i trust myself, VN,
and the Labs to write modules that make network connections, but not
anyone else, i need to tell who wrote a given module, right? otherwise it's
all-or-none. i'm either too restrictive or too permissive.

security consists of (at least?) two parts: authentication (who am i) and
authorization (what can i do). the file system model is an excelent way of
taking care of authorization, but something still needs to be done for
authentication, so i can trust people are who they say they are. dis signing
is one suggestion of how to do it.
-α.

Re: [9fans] Inferno plug-in security

[anothy]

//the basic idea in all Plan 9 and Inferno is, that even network connections
//are services offered by directories which are called "file systems"

you're correct, of cource. but think about it in terms of a normal file system,
like local disk or such. different users have different permissions to different
things, right? we can tell these users are different people because they have a
certain key/passwd/response. without signing on a dis module, we face two
problems, both of which exist in any system with no authentication. first,
when someone does something we don't like, we don't know who to blame.
if someone's doing things i don't like on my system, i want to know about it.
similarly, if i load a dis module that does things i don't like, i want to know
who wrote it and/or who gave it to me. second, without any reasonable
method of telling who's who, if i want to restrict _someone_ from doing
something, i have to restrict _everyone_. if, for example, i trust myself, VN,
and the Labs to write modules that make network connections, but not
anyone else, i need to tell who wrote a given module, right? otherwise it's
all-or-none. i'm either too restrictive or too permissive.

security consists of (at least?) two parts: authentication (who am i) and
authorization (what can i do). the file system model is an excelent way of
taking care of authorization, but something still needs to be done for
authentication, so i can trust people are who they say they are. dis signing
is one suggestion of how to do it.
-α.

Re: [9fans] Inferno plug-in security

[Anssi Porttikivi]

<anothy@cosym.net> wrote in message
news:<20010618153305.C69A519A08@mail.cse.psu.edu>...
> //if all sensitive system access is through the file system,
> //who cares about rogue Dis modules?
> 
> imagine i write a Limbo app that does nothing graphical,
> provides no indication to the user that it's running, but
> floods some site with network connections.

Hmmm... the basic idea in all Plan 9 and Inferno is, that even network
connections are services offered by directories which are called "file
systems", the /net/tcp... etc. files. A Limbo application can not open a
connection except by accessing the /net or /dev/ether or any of the
other possible FILE SYSTEMs, like those "objects" are called in Plan 9 /
Inferno parlance.

See http://www.vitanuova.com/inferno/papers/styx.html, part "Example:
networking".

Re: [9fans] Inferno plug-in security

[Rome Huang]

How about Java Applet's security?

Re: [9fans] Inferno plug-in security

[anothy]

//if all sensitive system access is through the file system,
//who cares about rogue Dis modules?

imagine i write a Limbo app that does nothing graphical,
provides no indication to the user that it's running, but
floods some site with network connections. get this
running on a few dozen people's machines, and i've got a
real nice distributed denial of service attack, all without
any of the participants being any the wiser. and if traced,
it'll come back to them, not me (the author).

also imagine i write something that tracks and reports
what you do after loading the app (mind you, i know
nothing about the plug-in structure, so i don't know if
that's possible). serious privacy concerns there, without
Dis signing. maybe still _with_ Dis signing, but at least
then you can make a more informed judgement.

and, of cource, while fs permissions are useful, they're
not the only thing that is. for example, why doesn't Bell
Labs hand out accounts on their machines? presumably
they employ file permissions reasonably, so i'd only be
able to read things that're "world" readable anyway, right?
permitting unidentified random people to run Dis modules
on your box is dangerous for exactly the same reasons.
-α.

Re: [9fans] Inferno plug-in security

[Anssi Porttikivi]

<rog@vitanuova.com> wrote in message
news:<20010615121808.9F1A119A1D@mail.cse.psu.edu>...
> yes, that's a possible type of approach, but i detect a certain amount
> of handwaving in your description...  restricting the accessible
> directories, or even read/write access to them, is probably not
> sufficient. (it couldn't give you selective access to different IP
> addresses, for example).

Certainly there was handwaving, and maybe imprecise conceptions of
Inferno or outright ignorance here. I just wonder, if my basic
Inferno/Plan 9 security architecture understanding is right:

The system services are file system "objects". They can be restricted or
augmented at will by programming and stacking new, similar file systems
on top of them by bind. Any "file" (a method) in a file system object
can be filtered or outright hidden with a simple script and bind, still
showing most "files" of the old file system object through.

Write a file system interface script that exports its own /net/tcp/n/ctl
pipe to filter all "connect" commands based on an IP address. Bind that
on top of /net. Let all other files show through from the original /net,
or #I. Or something similar. When a plug-in tries to open anything in
/net, let the user choose interactively a configuration of stacked
binds. These may implement any restrictions, and the interactive
security configurator needs only the path to them: just let the user
choose what to bind and where, when needed.

> and there still remains the question of how to deal with module
signing
> (which is necessary, in some form, even if you've got verified Dis, to
> prevent a module from creating its own Dis module (unverified) and
> calling that).

Hmmm...if all sensitive system access is through the file system, who
cares about rogue Dis modules? 

Re: [9fans] Inferno plug-in security

[Matt]

If you made it Open Source as is subsequent additions to it by third parties
would be outside of your control.

Matt

[9fans] Inferno plug-in security

[Anssi Porttikivi]

> like: what happens if someone puts a limbo app on a web page that
takes
> up no screen space, but dials out and does nefarious things (e.g.
> taking part in a DDOS attack).

Why don't you just give the plug-in user a simple configuration
interface to control what directories the plug in is allowed to access,
and in what ways (read/write/etc..)? This configuration could work
dynamically and popped up when non-existing directories are trying to be
opened during the execution of the plug-in.

Any file system "object" which is too liberal in its standard form can
be "stacked by"/"inherited to" a new restricted/augmented/modified
version. A selection of these can be provided with the plug-in,
programmed by the user, or done by a third party, maybe mounted from
elsewhere in the network.