John Carlson | 7 Apr 07:27 2012
Picon
Picon

Next Programming Acronym -- ClanJam

ClanJam - C, Linux, Apache, NodeJS, JavaScript, MySQL.
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Rolf Rander Næss | 11 Apr 08:00 2012

Re: What parts of a url are safe?

On Sat, Mar 31, 2012 at 04:52, James A. Donald <jamesd-twz8Zj9/99tBDgjK7y7TUQ@public.gmane.org> wrote:
What parts of a url are supposed to be safe to have secrets in?

If an addon or a plugin were to phone home with full urls, rather than
expurgated or truncated urls, would the addon be plausibly accused of
being spyware, and, if so accused, corrected to truncate the url to
avoid being placed on a spyware list?  Are there some parts of urls that
are not supposed to be passed around to all and sundry, that are
supposed to be safe to have secrets in?

URL-s are typically stored in full both in the browser history and in server logs.  If you go through a proxy (perhaps transparent), they are stored there as well.  In addition, if the connection doesn't use https, it is available to all routers/switches etc the connection passes thorugh.

It is reasonable to assume that all software running on the client, and all people having access to the server can read the URL-s in full.

I don't know if there exists a commonly accepted definition of "spyware", but there is probably a border between sending your own data to a server and sending some other applications data to a server.  In general, the information sent from client to server (using URL or other means) should be on a "need to know" basis.


regards

rolf rander

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Raffaello Giulietti | 19 Apr 15:05 2012
Picon

immutable objects

In section 9.1 of his unusual Ph.D. thesis, Mark S. Miller defines the
object-capability model.

Data is defined to be immutable information.

An instance, on the contrary, combines code and state. The latter is a
mutable map from indices to references.

A capability is defined as a reference to non-data, i.e., to an
instance, a device or a loader.

What about deeply immutable instances, like an immutable Point or an
immutable Date or even more complex immutable instances like an
immutable Person that maintains references to an immutable Address in
addition to Strings for names and a birth Date?

Are they only information? Is a reference to such an instance a capability?

On the other hand, is an instance to an immutable object (e.g.,
java.math.BigInteger) simply data or is a reference to it a full
capability, even if it points to immutable information?

In other words, where is the boundary between data and immutable instances?
Mark Miller | 19 Apr 19:38 2012
Picon

Re: immutable objects

On Thu, Apr 19, 2012 at 6:05 AM, Raffaello Giulietti <raffaello.giulietti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

In section 9.1 of his unusual Ph.D. thesis, Mark S. Miller defines the
object-capability model.

Unusual? Thanks I think ;).
 

Data is defined to be immutable information.

An instance, on the contrary, combines code and state. The latter is a
mutable map from indices to references.

A capability is defined as a reference to non-data, i.e., to an
instance, a device or a loader.



What about deeply immutable instances, like an immutable Point or an
immutable Date or even more complex immutable instances like an
immutable Person that maintains references to an immutable Address in
addition to Strings for names and a birth Date?

Are they only information? Is a reference to such an instance a capability?

On the other hand, is an instance to an immutable object (e.g.,
java.math.BigInteger) simply data or is a reference to it a full
capability, even if it points to immutable information?

In other words, where is the boundary between data and immutable instances?

The main purpose of this taxonomy is the following text from that same section:

Access to these are knowledge limited rather than permission limited. If Alice can figure out which integer she wants, whether 7 or your private key, she can have it. Data provides only information, not access. 
 
So the key issue is that capabilities are unforgeable whereas data can be resynthesized given only adequate information. The ocap model is purposely neutral on whether objects have identity. In an object system without identity, transitive immutability should be adequate. E objects in general have identity, so we define Data as <http://wiki.erights.org/wiki/Data>. The crucial bit of this regarding the present discussion is that Data is both transitively immutable and transitively identity-free.

Joe-E, because of the constraints that it be a no-rewrite subset of Java, can't avoid pervasive identity, even on individual BigIntegers. So we make a distinction via the marker interface Token as to whether the unforgeability of the identity of an object is supposed to be used for security purposes. The Joe-E "Powerless" type implies the object is transitively immutable and transitively purposeful-identity-free. If these "extra" unmarked identities are in fact not used, then Joe-E Powerless is effectively Data.

But strictly speaking, because of this unavoidable pervasive unforgeability of object identities, in Joe-E only scalars are Data.

--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Jed Donnelley | 22 Apr 20:53 2012

Re: Second is Webkeys or Passwords: Which is More Secure?

On 3/14/2012 4:53 PM, Marc Stiegler wrote:
> Second is Webkeys or Passwords: Which is More Secure?
> http://www.youtube.com/watch?v=C7Pt9PGs4C4

Ha!  Delightfully Stieglerian!

--Jed
Bill Frantz | 25 Apr 16:10 2012

Fwd: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-03.txt

A possible path for HTTPSY, the communication layer in E and 
other distributed systems etc.

====== Forwarded Message ======
Date: 4/25/12 6:19
Received: 4/25/12 9:20 -0400
From: internet-drafts@...
To: i-d-announce@...
CC: tls@...

A New Internet-Draft is available from the on-line 
Internet-Drafts directories. This draft is a work item of the 
Transport Layer Security Working Group of the IETF.

     Title           : TLS Out-of-Band Public Key Validation
     Author(s)       : Paul Wouters
                           John Gilmore
                           Samuel Weiler
                           Tero Kivinen
                           Hannes Tschofenig
     Filename        : draft-ietf-tls-oob-pubkey-03.txt
     Pages           : 10
     Date            : 2012-04-25

    This document specifies a new TLS certificate type for 
exchanging raw
    public keys in Transport Layer Security (TLS) and Datagram Transport
    Layer Security (DTLS) for use with out-of-band public key validation.
    Currently, TLS authentication can only occur via X.509-based Public
    Key Infrastructure (PKI) or OpenPGP certificates.  By 
specifying a
    minimum resource for raw public key exchange, 
implementations can use
    alternative public key validation methods.

    One such alternative public key valiation method is offered 
by the
    DNS-Based Authentication of Named Entities (DANE) together 
with DNS
    Security.  Another alternative is to utilize pre-configured 
keys, as
    is the case with sensors and other embedded devices.  The 
usage of
    raw public keys, instead of X.509-based certificates, leads 
to a
    smaller code footprint.

    The support for raw public keys is introduced into TLS via a 
new non-
    PKIX certificate type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-03.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/

_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls

====== End Forwarded Message ======
-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 
Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, 
CA 95032
Ben Laurie | 28 Apr 19:31 2012
Picon

Sandboxing with Capsicum

People might be interested in this post.

http://www.links.org/?p=1242

Using Capsicum For Sandboxing

FreeBSD 9.0, released in January 2012, has experimental Capsicum support in the kernel, disabled by default. In FreeBSD 10, Capsicum will be enabled by default.

But unless code uses it, we get no benefit. So far, very little code uses Capsicum, mostly just experiments we did for our paper. I figured it was time to start changing that. Today, I’ll describe my first venture – sandboxing bzip2. I chose bzip2 partly because Ilya Bakulin had already done some of the work for me, but mostly because a common failure mode in modern software is mistakes made in complicated bit twiddling code, such as decompressors and ASN.1 decoders.

These can often lead to buffer overflows or integer over/underflows – and these often lead to remote code execution. Which is bad. bzip2 is no stranger to this problem: CVE-2010-0405 describes an integer overflow that could lead to remote code execution. The question is: would Capsicum have helped – and if it would, how practical is it to convert bzip2 to use Capsicum?

The answers are, respectively, “yes” and “fairly practical”.

First of all, how does Capsicum mitigate this problem? The obvious way to defend a decompressor is to run the decompression engine in a separate process with no privilege beyond that needed to get its job done – which is the ability to read the input and write the output. In Capsicum, this is easy to achieve: once the appropriate files are open, fork the process and enter capability mode in the child. Discard all permissions except the ability to read the input and write the output (in Capsicum, this means close all other file descriptors and limit those two to read and write), and then go ahead and decompress. Should there be a bug in the decompressor, what does the attacker get? Well, pretty much what he had already: the ability to read the input file (he supplied it, so no news there!) and the ability to write arbitrary content to the output file (he already had that, since he could have chosen arbitrary input and compressed it). He also gets to burn CPU and consume memory. But that’s it – no access to your files, the network, any other running process, or anything else interesting.

I think that’s pretty neat.

But how hard is it to do? I answer that question in a series of diffs on GitHub, showing a step-by-step transformation of bzip2 into the desired form. I used a technique I like to call error-driven development; the idea is you attempt to make changes that will cause compilation to fail until you have completely accomplished your goal. This is a useful way to reassure yourself that you have made all necessary updates and there’s nothing hiding away you didn’t take care of. If you follow along by building the various stages, you’ll see how it works.

It turns out that in bzip2 this matters – it isn’t very beautifully written, and the code that looks like it might cleanly just take an input file and an output file and do the work in isolation, actually interacts with the rest of the code through various function calls and globals. This causes a problem: once you’ve forked, those globals and functions are now in the wrong process (i.e. the child) and so it is necessary to use RPC to bridge any such things back to the parent process. Error-driven development assures us that we have caught and dealt with all such cases.

So how did this work out in practice? Firstly, it turns out we have to give the compressor a little more privilege: it writes to stderr if there are problems, so we need to also grant write on stderr (note that we could constrain what it writes with a bit more effort). The callbacks we have to provide do not, I think, let it do anything interesting: cause the program to exit, make the output file’s permissions match the input file’s, and remove the input or output files (ok, removing the input file is slightly interesting – but note that bzip2 does this anyway).

Secondly, because we have not yet decided on an RPC mechanism, this particular conversion involves quite a bit of boilerplate: wrapping and unwrapping arguments for RPCs, wiring them up and all that, all of which would be vastly reduced by a proper RPC generator. Try not to let it put you off 

Finally, the system has (at least) one global, errno. I did not deal with that so far, which means some errors will report the wrong error – but it is not particularly hard to do so.

So, on to the diffs. This is something of an experimental way to present a piece of development, so I’d be interested in feedback. Here they are, in order:

And there you are: bzip2 is now rendered safe from decompressor exploits, and it was only a few hours work. As we refine the support infrastructure, it will be even less work.


_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

Gmane