On Thu, May 05, 2016 at 12:59:37PM -0400, Greg Troxel wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> > On Thu, May 05, 2016 at 10:49:19AM -0400, Greg Troxel wrote:
> >> Last I looked, there was the possibility of some fs data to travel
> >> unencrypted if it was not associated with a logged-in user.  This is in
> >> my view totally not ok.
> >
> > It is encrypted but there is no shared secret between the client and the
> > server during the connection setup handshake, so the session key is
> > encrypted with a commonly known 'null key'. If you capture the INIT2
> > packet from the server to the client you can trivially decrypt it and
> > get the session key.
> >
> > But.. why would anybody go through that amount of trouble if he can
> > connect to the server without authentication himself and get those same
> > files anyway? Clearly their ACL must allow System:AnyUser access,
> > otherwise the user would have had to be logged-in.
> 
> Perhaps.  But my security model involves the notion of limiting access
> entirely to an authorized set, and I'd like that to be super clear.
> Perhaps that a coda config setting that denies all unauthenticated
> access.

Well, right now we set 2 default ACLs when the root directory of a new
volume is created. "System:Administrators all System:AnyUser rl", these
are hardcoded and normally changed right after the volume is created to
allow the designated user of a volume access at which point I normally
set "System:AnyUser none". Leaving admin access is useful for helping
with the inevitable server-server conflict repair :)

For what you propose, Coda would need to introduce something like a new
System:AuthenticatedUser group that can be used instead of AnyUser. Or
maybe an even more flexible 'this is the default acl that should be set
when creating a new volume' setting. It is actually hard to do this
right at the createvol_rep scripting level because setting acls requires
access to the volume through /coda, but right after creation the volume
isn't mounted anywhere, and the VRDB/VLDB databases may not even be
synced to all servers yet so even if we force a temporary mount the
mountpoint may not resolve right away.

Jan