[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
ACLs null on NT
- To: or-talk@xxxxxxxx
- Subject: ACLs null on NT
- From: Lee Fisher <blibbet@xxxxxxxxx>
- Date: Mon, 07 Aug 2006 14:22:39 -0700
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivery-date: Mon, 07 Aug 2006 17:24:20 -0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=K8tx2Zn6TuOT8PGJ1A1aV1HJBOwBTDGXul1IXhUlTGbowk4mxC3K+k4H2y6kp8bXF4U6ypoRIOCX8iPG3y4TH+3lGtm1zBGK8nkGcHUWLArpdldU5COq0B/wRU/pdZ+oQXdeMh/ezeLr7n2Ohe87xSzXEtPj0Lx2A8Nr0En3Ktc=
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
- User-agent: Thunderbird 188.8.131.52 (Macintosh/20060516)
-----BEGIN PGP SIGNED MESSAGE-----
I'm new here, I'm reviewing the code and spec, trying to find out more
about bug 98 (WindowsBufferProblems wiki page). Here is an unrelated
observation, constructive feedback about how to improve security for Tor
on NT a little.
I notice that NULL ACLs are being used. Libevent's win32-code/misc.c's
socketpair() calls CreateNamedPipe() and CreateFile(), both of which
have their last parameter, lpSecurityAttributes, set to NULL. With no
ACL, the process gets the default ACL. I believe this means that
multiple user groups gets write access, and Everyone gets read access
when NULL is specified as the ACL (forcing the default ACL with
Also socketpair() it calls SetNamedPipeHandleState() but doesn't check
the return code, not ACL-related but it should be fixed.
Tor's or/main.c's tor_init() checks if it is being run as root/admin,
but only for non-NT codepath, no control flow change, just fyi spew.
The code should be fixed to explicitly set ACLs, the SDK has samples
that show this. Or at least the spec should be updated to reduce NT
security expectations to be theoretical like BSD. Giving the NT Tor
service a separate user account to help isolate things would be better.
Sorry, no patches. Back to bug 98...
Tor control-spec excerpt:
Write a named socket in tor's data-directory or in some other location;
rely on the OS to ensure that only authorized users can open it. (NOTE:
the Linux unix(7) man page suggests that some BSDs don't enforce
authorization.) If the OS has named sockets, and implements
authentication, trust all users who can read Tor's data directory.
If lpSecurityAttributes is NULL, the named pipe gets a default security
descriptor and the handle cannot be inherited. The ACLs in the default
security descriptor for a named pipe grant full control to the
LocalSystem account, administrators, and the creator owner. They also
grant read access to members of the Everyone group and the anonymous
To create an instance of a named pipe by using CreateNamedPipe, the user
must have FILE_CREATE_PIPE_INSTANCE access to the named pipe object. If
a new named pipe is being created, the access control list (ACL) from
the security attributes parameter defines the discretionary access
control for the named pipe.
For backward compatibility purposes, CreateFile does not apply Windows
2000 inheritance rules when you specify a security descriptor in
lpSecurityAttributes. To support inheritance on Windows 2000 and later,
APIs that later query the security descriptor of this object may
heuristically determine and report that inheritance is in effect. See
Automatic Propagation of Inheritable ACEs for more information about
inheritance rules in Windows 2000 and later operating systems, and how
they differ from previous versions of Windows.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----