Discussion:
[cap-talk] Challenge problem from David Mazieres
David Wagner
2006-12-12 08:50:04 UTC
Permalink
MarkM has been looking around for security challenge problems.
I've got one to add to the list. I've been having an email
conversation with David Mazieres about the HiStar system, and he
raised an interesting problem that I think fits the bill.

You've got a laptop. While travelling, you sometimes connect
to the public Internet unprotected ("skinnydipping"). While at
home, you sometimes connect to your work's intranet over a VPN.
The desired security policy is this: any data you got over the
public Internet must be scanned with a virus scanner before it
can be sent to your work's intranet via the VPN.

Question: How do we enforce this policy? Of course, the real
question is how a capability system can be used to enforce this
desired policy, and whether capabilities provide any extra leverage.

In David Mazieres' formulation, he wanted an OS solution that
would work with legacy applications, but we could presumably
relax that a bit. For instance, if you've got in mind a hypothetical
capability-based desktop, a la CapDesk, then we could ask how your
desktop could enforce this policy without making unreasonable changes
to all your applications.

Any takers?

(My first reaction: This problem is orthogonal to the kinds of
problems that capability systems usually try to solve. Consequently,
capability systems might not have any special advantage at enforcing
this kind of policy. That seems ok; capabilities aren't a silver
bullet, and they don't solve every problem in the world. But maybe
others have a different reaction, or can see some clever way in which
capabilities would make this problem easier to solve.)
Mark S. Miller
2006-12-12 10:19:54 UTC
Permalink
Post by David Wagner
The desired security policy is this: any data you got over the
public Internet must be scanned with a virus scanner before it
can be sent to your work's intranet via the VPN.
Is it adequate for a solution to simply virus-scan all data before sending it
over the VPN? Alternatively, is it adequate to simply virus-scan all data
received from the public Internet?
--
Text by me above is hereby placed in the public domain

Cheers,
--MarkM
David Hopwood
2006-12-12 17:05:43 UTC
Permalink
Post by David Wagner
MarkM has been looking around for security challenge problems.
I've got one to add to the list. I've been having an email
conversation with David Mazieres about the HiStar system, and he
raised an interesting problem that I think fits the bill.
You've got a laptop. While travelling, you sometimes connect
to the public Internet unprotected ("skinnydipping"). While at
home, you sometimes connect to your work's intranet over a VPN.
The desired security policy is this: any data you got over the
public Internet must be scanned with a virus scanner before it
can be sent to your work's intranet via the VPN.
Question: How do we enforce this policy? Of course, the real
question is how a capability system can be used to enforce this
desired policy, and whether capabilities provide any extra leverage.
In David Mazieres' formulation, he wanted an OS solution that
would work with legacy applications, but we could presumably
relax that a bit. For instance, if you've got in mind a hypothetical
capability-based desktop, a la CapDesk, then we could ask how your
desktop could enforce this policy without making unreasonable changes
to all your applications.
Any takers?
- Confine the browser (and any other application with direct internet
access) that is used for 'skinnydipping'. It should already have been
designed to be confineable, along similar lines to the DarpaBrowser.

- Add a hook to the browser's powerbox so that is unable to write
anything outside its own private file area, unless it has been
virus-checked. This can be implemented by wrapping any directory
capabilities returned to the browser.
--
David Hopwood <***@blueyonder.co.uk>
David Wagner
2006-12-12 16:56:30 UTC
Permalink
Post by Mark S. Miller
Post by David Wagner
The desired security policy is this: any data you got over the
public Internet must be scanned with a virus scanner before it
can be sent to your work's intranet via the VPN.
Is it adequate for a solution to simply virus-scan all data before sending it
over the VPN? Alternatively, is it adequate to simply virus-scan all data
received from the public Internet?
Beats me. I guess part of the challenge is filling in the details of
the challenge problem. :-)

Here would be my vote. It might be interesting to try answering it
either way, but I think it's probably a more interesting problem if the
answer to both of your questions is taken to be "No".

For instance, you just know that someone is going to propose the
following variation of the problem, where the desired security policy
is to not allow any data you got over the public Internet to be sent to
your work's intranet via the VPN. If we answer "No" to both of your
questions, then this variation is just a special case of the problem
I posed (the special case where the virus scanner always says "virus
found, transfer forbidden" for any file fed to it). If we answer "Yes"
to your questions, we'll have to think about the variation separately.

P.S. To forestall another possible question, I personally think we should
interpret this to refer only to overt channels of communication, and to
ignore all covert channels. Also, I think we should assume that the
user might have many different networked applications that he uses to
access the Internet/intranet, so we don't want to have to change them all.
Sandro Magi
2006-12-12 17:10:43 UTC
Permalink
Not the most efficient solution, but serves to highlight the flexibility
of EROS-style systems:

Have a different "network interface" domain for each network you connect
to. You can thus apply custom filters to any data passing through a
particular interface, ie. virus-checking and firewalls on the open
network, and no filters on the VPN.

Sandro
Post by David Wagner
MarkM has been looking around for security challenge problems.
I've got one to add to the list. I've been having an email
conversation with David Mazieres about the HiStar system, and he
raised an interesting problem that I think fits the bill.
You've got a laptop. While travelling, you sometimes connect
to the public Internet unprotected ("skinnydipping"). While at
home, you sometimes connect to your work's intranet over a VPN.
The desired security policy is this: any data you got over the
public Internet must be scanned with a virus scanner before it
can be sent to your work's intranet via the VPN.
Question: How do we enforce this policy? Of course, the real
question is how a capability system can be used to enforce this
desired policy, and whether capabilities provide any extra leverage.
In David Mazieres' formulation, he wanted an OS solution that
would work with legacy applications, but we could presumably
relax that a bit. For instance, if you've got in mind a hypothetical
capability-based desktop, a la CapDesk, then we could ask how your
desktop could enforce this policy without making unreasonable changes
to all your applications.
Any takers?
(My first reaction: This problem is orthogonal to the kinds of
problems that capability systems usually try to solve. Consequently,
capability systems might not have any special advantage at enforcing
this kind of policy. That seems ok; capabilities aren't a silver
bullet, and they don't solve every problem in the world. But maybe
others have a different reaction, or can see some clever way in which
capabilities would make this problem easier to solve.)
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk
David Wagner
2006-12-12 17:06:54 UTC
Permalink
Post by David Hopwood
- Confine the browser (and any other application with direct internet
access) that is used for 'skinnydipping'. It should already have been
designed to be confineable, along similar lines to the DarpaBrowser.
- Add a hook to the browser's powerbox so that is unable to write
anything outside its own private file area, unless it has been
virus-checked. This can be implemented by wrapping any directory
capabilities returned to the browser.
I like this, as a starting point for discussion.
However, I have two questions:

- Does this mean that the browser instance I use to browse the
public Internet cannot share any settings or preferences with
the browser instance I use when connected to my intranet? In
essence, I have to configure every network application twice,
and manually synchronize them? I can see some ways how one
might avoid that, but they may require modifying every network
application that I might use while connected to the Internet.

- Doesn't this require modifying (the powerbox part of) every
network application that I might use while connected to the
public Internet, to support this sort of virtualization?
David Hopwood
2006-12-12 20:27:14 UTC
Permalink
Post by David Wagner
Post by David Hopwood
- Confine the browser (and any other application with direct internet
access) that is used for 'skinnydipping'. It should already have been
designed to be confineable, along similar lines to the DarpaBrowser.
- Add a hook to the browser's powerbox so that is unable to write
anything outside its own private file area, unless it has been
virus-checked. This can be implemented by wrapping any directory
capabilities returned to the browser.
I like this, as a starting point for discussion.
- Does this mean that the browser instance I use to browse the
public Internet cannot share any settings or preferences with
the browser instance I use when connected to my intranet?
No, it can share settings. To make sure that these settings cannot be
used as a channel between instances, we can do something like this:

- there is a settings editor UI which is a separate component to the
rest of the browser. The confined instances never write to the settings
directly; they just have read-only access, plus the ability to make
the settings editor appear when the user asks for it (and it is not
already displayed).

- the settings editor has the ability to display a (labelled) window,
and its interface essentially acts as a function from old to new
settings. It doesn't need, and therefore doesn't have, any network
or filesystem access.

With two browser instances, the information flow in this system is:

<pre>

.----------------> [ user ] <----------------.
| ^ |
v | v
[ Internet ] v [ intranet ]
[ browser ] <---- [ settings editor ] ----> [ browser ]
^ | | ^
| | | |
| '---------> [ virus checker ] | |
| | | |
| v | |
| [ filesystem ] <-----------' |
| |
v v
( Internet ) <-------> [ VPN bridge ] <------> ( intranet )

</pre>

Note that information cannot get from the network cloud to the filesystem
other than:
- via the virus checker;
- via the VPN bridge;
- by the user cutting and pasting (or retyping) between applications.

I think that cutting and pasting is probably out of scope for this problem,
although it could be addressed in something like the EROS Window System
design: <http://www.sagecertification.org/events/sec04/tech/shapiro.html>.

I imagine that a capability-based desktop environment would already have a
framework implementing the above, because it is such a common requirement to
be able to share settings between otherwise confined application instances.

(The problem statement begs the question of why you would not want the files
saved by the intranet browser also to be virus checked -- bearing in mind
that false positive virus indications are quite common, and would need to be
overridable by the user in any case. But hopefully the advantage of being
able to prevent direct communication between application instances, while
still allowing them to share settings, is clear in any case.)

Note that routinely separating the settings editor for each application from
the rest of the app has some other advantages: it would make it easier to
manage (back up, roll back, share between user accounts, limit according to
organisational policy) settings in a uniform way for all applications.
This could well improve usability, compared to the mess of settings handled
differently by each app in current operating systems.
Post by David Wagner
In essence, I have to configure every network application twice,
and manually synchronize them? I can see some ways how one
might avoid that, but they may require modifying every network
application that I might use while connected to the Internet.
- Doesn't this require modifying (the powerbox part of) every
network application that I might use while connected to the
public Internet, to support this sort of virtualization?
That's why I said 'add a hook to the browser's powerbox'. Running some
boolean predicate on file contents before allowing them to be saved is
such an obviously useful facility, then we can reasonably expect it to
have been anticipated. (In fact, it's insane that virus checkers don't
already work that way.) If we have more than one predicate to run, we can
'and' them without requiring them to have knowledge of each other.

In any case, the powerbox that needs to be changed/hooked here is logically
part of the shell, not of the app.
--
David Hopwood <***@blueyonder.co.uk>
David Hopwood
2006-12-12 22:02:05 UTC
Permalink
Post by David Hopwood
<pre>
.----------------> [ user ] <----------------.
| ^ |
v | v
[ Internet ] v [ intranet ]
[ browser ] <---- [ settings editor ] ----> [ browser ]
^ | | ^
| | | |
| '---------> [ virus checker ] | |
| | | |
| v | |
| [ filesystem ] <-----------' |
| |
v v
( Internet ) <-------> [ VPN bridge ] <------> ( intranet )
</pre>
Note that information cannot get from the network cloud to the filesystem
- via the virus checker;
- via the VPN bridge;
- by the user cutting and pasting (or retyping) between applications.
I meant, "from the Internet to the filesystem".
--
David Hopwood <***@blueyonder.co.uk>
David Wagner
2006-12-12 17:11:27 UTC
Permalink
Post by Sandro Magi
Not the most efficient solution, but serves to highlight the flexibility
Have a different "network interface" domain for each network you connect
to. You can thus apply custom filters to any data passing through a
particular interface, ie. virus-checking and firewalls on the open
network, and no filters on the VPN.
I don't follow. It sounds like we have a layering mismatch. By
"interface", I assume you are talking at the level of the TCP/IP stack
or of the Ethernet interface. But at that level of the system, the code
only sees Layer 2 or Layer 3 packets, whereas the security policy is
about application-layer semantics. For instance, let's say you use your
web browser to read your email by navigating to https://www.hotmail.com
and using Hotmail's webmail interface, then you save an attachment that
someone sent you to your hard disk. The TCP/IP stack or Ethernet driver
has no chance of reconstructing the file contents from the bits flying
over the wire; it is going to see random-looking bits (SSL ciphertexts),
and the bits it sees may have an extremely indirect relationship to the
way those bits are interpreted by the application. Am I misunderstanding
your proposed solution?
Sandro Magi
2006-12-12 17:44:13 UTC
Permalink
Post by David Wagner
Post by Sandro Magi
Not the most efficient solution, but serves to highlight the flexibility
Have a different "network interface" domain for each network you connect
to. You can thus apply custom filters to any data passing through a
particular interface, ie. virus-checking and firewalls on the open
network, and no filters on the VPN.
I don't follow. It sounds like we have a layering mismatch. By
"interface", I assume you are talking at the level of the TCP/IP stack
or of the Ethernet interface. But at that level of the system, the code
only sees Layer 2 or Layer 3 packets, whereas the security policy is
about application-layer semantics. For instance, let's say you use your
web browser to read your email by navigating to https://www.hotmail.com
and using Hotmail's webmail interface, then you save an attachment that
someone sent you to your hard disk. The TCP/IP stack or Ethernet driver
has no chance of reconstructing the file contents from the bits flying
over the wire; it is going to see random-looking bits (SSL ciphertexts),
and the bits it sees may have an extremely indirect relationship to the
way those bits are interpreted by the application. Am I misunderstanding
your proposed solution?
Yes and no. I agree it would be difficult to analyze at some layers
(although some ISPs do it anyway), but given a "componentized" system
like EROS, the interposition of a filter can be done at *any* layer,
Ethernet, TCP/IP, post-decryption, file system, http and https protocols
can be implemented in their own components, between which a filter could
analyze requests/responses, etc.

However, I am assuming that we are designing the system from scratch to
enable these patterns (though any sufficiently componentized system
would probably suffice), and not trying to retrofit existing
applications into this usage model.

If you're trying to do this with Firefox, I think you'd have to
interpose a virus scanning filter in front of the file system. That may
not be enough if you keep the application running while you switch
networks though. Interesting challenge.

Sandro
Jonathan Smith
2006-12-12 20:51:46 UTC
Permalink
The SubOS ideas may be relevant here.

http://citeseer.ist.psu.edu/421583.html

-JMS
Post by Sandro Magi
Post by David Wagner
Post by Sandro Magi
Not the most efficient solution, but serves to highlight the
flexibility
Have a different "network interface" domain for each network you connect
to. You can thus apply custom filters to any data passing through a
particular interface, ie. virus-checking and firewalls on the open
network, and no filters on the