Re: [capsicum] constructing a pure file descriptor from a capability




Ah, I see. So, the general pattern you're using here is called rights
amplification - i.e. if I have capabilities A and B then I am also
allowed C (usually C is more rights on A or B). But not sure why
you're using it in this case - why doesn;'t the socket wrapper return
a cap to the connect wrapper instead of the useless cap?

So it depends on what kind of connect wrapper we're talking about:

1. If the connect wrapper does a policy check, then we can just let any client code call it, and we don't need to wrap access to it with a capability (this is the approach that I'm currently planning on).

2. If the connect wrapper doesn't do a policy check, then for the program to be secure, the socket wrapper must only grant the capability to call the connect wrapper based on if a policy check succeeds. But I can't see how to make this work, given that our policy check is defined over the arguments to connect(), not the arguments to socket() (and I can't really see how any practical policy can be defined over the arguments to socket(): they just don't seem to have the information that a policy writer would be interested in).

-Bill
 

>
> -Bill
>
>
>>
>>
>> >
>> > -Bill
>> >
>> >
>> >
>> > On Tue, Nov 27, 2012 at 4:51 PM, Ben Laurie <ben at links.org> wrote:
>> >>
>> >> On Tue, Nov 27, 2012 at 10:07 PM, Bill Harris <wrharris at cs.wisc.edu>
>> >> wrote:
>> >> > Folks,
>> >> >
>> >> > I'd like your input on a Capsicum programming problem. The context
>> >> > for
>> >> > this
>> >> > problem is that I would like to use Capsicum to enforce a policy over
>> >> > sockets. The policy is defined by checking the arguments in each call
>> >> > to
>> >> > connect(), and only going through with the call to connect() if the
>> >> > arguments satisfy some policy.
>> >> >
>> >> > The challenge with enforcing this policy is that there are really two
>> >> > steps
>> >> > two creating a useful socket.
>> >> >
>> >> > 1. Create the socket by calling socket().
>> >> > 2. Bind the socket to a resource (by calling, e.g., connect()).
>> >> >
>> >> > To enforce a policy over sockets with untrusted code, it seems like
>> >> > you
>> >> > need
>> >> > to rewrite the program to do something like the following:
>> >> >
>> >> > 1. Replace socket() with a socket() wrapper. The socket wrapper
>> >> > creates
>> >> > the
>> >> > socket, and then restricts it to a "useless capability" with no
>> >> > rights.
>> >> > 2. Replace connect() with a connect() wrapper. The connect wrapper
>> >> > checks
>> >> > its arguments against some policy. The descriptor argument will
>> >> > always
>> >> > be a
>> >> > useless capability created by the socket wrapper. If the values
>> >> > satisfy
>> >> > the
>> >> > policy, then the connect wrapper does Something Clever to turn the
>> >> > useless
>> >> > capability into a capability with the set of access rights dictated
>> >> > by
>> >> > the
>> >> > policy.
>> >> >
>> >> > My main question concerns how to implement the Something Clever of
>> >> > (2).
>> >> > In
>> >> > Capsicum, is there a clean way for a process to convert a capability
>> >> > into a
>> >> > non-capability file-descriptor if the process is not in capability
>> >> > mode?
>> >> > I
>> >> > realize that lifting restrictions on capabilities is a bit odd and
>> >> > dangerous
>> >> > a thing to want, but given that a process not in capability mode can
>> >> > essentially do whatever it wants anyways, it seems plausible, and I
>> >> > figured
>> >> > I'd ask.
>> >> >
>> >> > By the way, if it turns out that there's no way to convert a
>> >> > capability
>> >> > back
>> >> > to a raw file descriptor, here's my current plan:
>> >> >
>> >> > 1. In the socket wrapper, after the wrapper opens a socket, it sends
>> >> > the
>> >> > raw
>> >> > socket to a "socket server" process that executes not in capability
>> >> > mode. It
>> >> > then turns its raw descriptor into a useless capability.
>> >> > 2. In the connect wrapper (which executes not in capability mode), if
>> >> > the
>> >> > arguments pass the policy check, then the wrapper asks the sockets
>> >> > server
>> >> > for the raw socket corresponding to the useless capability given as
>> >> > an
>> >> > argument. The socket server tests that the requesting process is not
>> >> > in
>> >> > capability mode, and if so, grants the raw socket.
>> >> >
>> >> > If you see any issues with this or see any ways to improve it, please
>> >> > let me
>> >> > know.
>> >>
>> >> Basically, you have the right idea, but a major cockup in
>> >> implementation: the policy check must be done at the sockets server
>> >> end - clearly once the client is owned it can ask that server to do
>> >> anything.
>> >>
>> >> >
>> >> > Thanks,
>> >> > Bill
>> >
>> >
>
>



This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.