[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #2972 [Tor Client]: Allow ControlSocket to be group writable
#2972: Allow ControlSocket to be group writable
-------------------------+--------------------------------------------------
Reporter: lunar | Owner:
Type: enhancement | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.2.x-final
Component: Tor Client | Version: Tor: unspecified
Keywords: | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by nickm):
Replying to [comment:9 rransom]:
> Replying to [comment:8 Sebastian]:
> > Replying to [comment:7 nickm]:
> > > I like this idea, but think that depending on the default group
seems error-prone. Perhaps instead of a boolean, it could take the name
of a group, and chgrp the socket before doing the chmod? That seems less
likely to wind up with surprising results.
> >
> > Do you think the same applies to the case of cookie auth?
>
> I don't think relying on the default group is error-prone at all. Tor's
documentation states that it when it is started as root and the User
option is specified, it changes to that user ID and the default group
associated with that user ID; that appears to work correctly on Linux
2.6.x with glibc and FreeBSD 8.2-RELEASE-p1.
I'm not saying it's error-prone because of a lack of documentation; I'm
saying it's error-prone because it's not too hard for people to get
confused about which group is in fact the default group for a given user
at a given time. If you think you've set it up so that you're running as
user=tor group=tor but in fact you're running as user=tor group=users,
then you're in deep trouble. Specifying the group explicitly makes this
kind of error basically impossible to do.
> > > Finally, the linux unix(7) manpage says:
> {{{
> Connecting to the
> socket object requires read/write permission. This behavior
differs
> from many BSD-derived systems which ignore permissions for Unix
sockâ
> ets. Portable programs should not rely on this feature for
security.
> }}}
> > >
> > > Is this true nowadays? If so, we shouldn't give people a false
sense of security by allowing this option where it won't work.
>
> Part of the reason I started using FreeBSD was so that I could test that
fact. I haven't tested it or RTFSed yet, but the
[http://www.freebsd.org/cgi/man.cgi?query=unix&apropos=0&sektion=4&manpath=FreeBSD+8.2-RELEASE&format=html
unix(4)] and
[http://www.freebsd.org/cgi/man.cgi?query=connect&apropos=0&sektion=2&manpath=FreeBSD+8.2-RELEASE&format=html
connect(2)] man pages seem to say that FreeBSD currently does not allow
users without write access to a local socket to connect to it.
>
> > We should probably disable the !ControlSocket option altogether on
such systems, or at least warn loudly when it is used?
>
> There is enough FUD out there about whether filesystem permissions on
local sockets are enforced that I would recommend removing the
!ControlSocket option. It isn't even reliably possible to determine which
kernel a compiled executable is running on anymore.
Well, we could always make a socket at runtime, give it permissions 000,
and then try to write to it. :/
Personally I want to know which live systems actually have this problem
before we remove a feature based on some kernels not doing it right.
I'm attaching a pair of test programs that should compile on most unixes.
One verifies that we honor mode 000 on AF_UNIX sockets; the other verifies
that we check permissions in the directory path when connecting to AF_UNIX
sockets. If we can find extant tor-supported platforms where the answer
is "no", that's something we should act on.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2972#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs