On 24-06-2010 23:31, Jeffrey Walton wrote:
Hi Massimiliano,
If the locks need to be shared across processes, use a Mutex (the
mutexes can be named for separate processes, or the mutex can be
unnamed if Object Handle Inheritance is used (a flag to CreateProcess,
which is similar to fork(2))).
Otherwise, use a CRITICAL_SECTION. The critical section is more
efficient when only threads of a single process will access shared
data. The efficiency comes from a user land spin, which side steps the
kernel transition if possible. If the spin fails, the thread will have
to transition (the CRITICAL_SECTION is *really* backed by an Event
Object).
Please note that Win32 locking is already built into openssl (see my
other post).
Critical sections have the added benefit that you don't have to supply
a SECURITY_ATTRIBUTES. Mutexes take a SECURITY_ATTRIBUTES, which many
folks leave unspecified (NULL) so the net effect is "Everyone, Full
Control". Code which uses a NULL SECURITY_ATTRIBUTES *should* fail a
security audit.
This is plain wrong, and I certainly hope nobody uses this
misunderstanding in security audits.
There are 4 levels of indirection for Win32 calls that take a
SECURITY_ATTRIBUTES* as argument, and the (standard) implications
of passing NULL or non-NULL at each level differs.
1. If you pass NULL for the (SECURITY_ATTRIBUTES*) argument, the
handle will not be inherited across CreateProcess, and the object
created (if any) will get the context specific default (usually
good enough) security permissions. For Files/Registry Keys/Active
Directoy Objects etc. The default permissions are inherited from
the folder the new object is placed in. For Events, Mutexes, Threads
and other such "parentless" objects, the default permissions are
specified in the log-in token of the calling thread/process. Usually
this grants access to the user himself and to trusted operating system
processes, but you can change that if you know what you are doing.
Note that this is the exact same permissions which control the
ability to debug or otherwise manipulate your process in its entirety,
so unless you change those permissions first, changing the default
permissions is rather pointless.
2. If you pass NULL for the lpSecurityDescriptor member of a real
SECURITY_ATTRIBUTES structure, the handle may be inherited across
CreateProcess according to the boolean field in SECURITY_ATTRIBUTES,
but the permissions assigned are still the default as above.
Beware that if you pass non-NULL for lpSecurityDescriptor, your
call will fail on Windows 95/98/Me because the ACL features are
not implemented by those systems.
3. If you pass an actual SECURITY_DESCRIPTOR opaque object in the
lpSecutityDescriptor field, but do not set the "DACL" part of that
security descriptor, the DACL will still be set to the default value
as above, but you get a chance to override the 3 other pieces of
security information: Owning User (as in UNIX chown), Owning Group
(as in UNIX chown) and Audit Logging descriptor (SACL).
4. If you actually go to the trouble of setting up all the previous
structures, AND explicitly sets the DACL in it to NULL rather than
unassigned or a carefully written value, then you create an insecure
object accessible to all accounts, even the "null session" account which
is not even a member of EveryOne. This is highly depreciated,
and Microsoft has repeatedly hinted that this feature might one day
go away.
P.S.
Bizarrely, in many versions of Windows, unnamed Event and Mutex object
do not store or enforce their security settings. I guess the designers
thought that since such objects can only be passed around via
inheritance and handle duplication, there can be no unauthorized access
attempts, but they kind of forgot about the permission changing options
in DuplicateHandle().
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
