[Openswan dev] Re: user control of conns

[D. Hugh Redelmeier]

| From: Michael Richardson <mcr at sandelman.ottawa.on.ca>

| DHR, I wrote a minimal version of whack that can only do --initiate
|      and --terminate. 

I haven't thought carefully about the implications.  Sounds useful.

Consider the parallel with mount.  /etc/fstab has option "user" and
"owner" to control and authorize non-superusers to mount file systems.
Probably conns/connections need some analogous attribute.  Perhaps
even one explicitly restricting the user's UID or GID.

| It was my intention to make this program setuid root, such that it could
| talk to the whack socket. 
| 
| On the other hand, making the whack socket have group permissions
| permits the executable either to be setgid() instead, or for the user to
| actually be a member of a "pluto" (or "ipsec" ??) group.

It is always better to limit capabilities.  Group sounds better
(again, without careful consideration).

It takes a lot of care to write suid code responsibly.  sgid is a
little less onerous (but not for the careless).

In theory, It might be nice to allow more than one IPSEC
implementation to coexist.  Pluto was designed to allow different IKE
daemons on different interfaces.  So I'd be in favour of "pluto" or
"openswan" groups rather than "ipsec".

| What do you think?
| 
| a) setuid-root permits pluto to remain very much isolated.
|    Access control to the binary can be via group permissions on the 
|    executable.
| 
| b) setgid-pluto permits pluto to be controlled more easily, but anyone
|    that can run the setgid program can up/down conns.
|    (alas, groups are overloaded --- both to decide who can run the
|    executable, and to decide what to setgid to. The program could be
|    setgid-pluto, and it could then check the gid-vector for a second
|    group of people who are permitted to change states)

Another choice would be setuid-pluto.  Don't know if that is a good
choice, but it should be considered.  Sadly, pluto itself must be run
as root -- it does too many privileged things.

| Note that group access to /var/run/pluto_ctl means that anyone in the
| pluto group can load new policy, etc. which is *not* the intention of
| whackinit.

Right.  The group is not for users, just programs and files.

| Rather the goal was to permit a mortal user to start/stop a VPN.
| I think that loading a conn should definitely require root. Thus I am
| shying away from group permissions on the socket.

As long as the only sgid openswan program is limitted whack, it should
be possible to do this with groups, I think.