On 22 July 2015 at 21:49, Graham Bloice <graham.blo...@trihedral.com> wrote:
> > > On 22 July 2015 at 18:37, Guy Harris <g...@alum.mit.edu> wrote: > >> >> On Jul 22, 2015, at 9:37 AM, Graham Bloice <graham.blo...@trihedral.com> >> wrote: >> >> > Most, if not all, will be running Wireshark unelevated, as this is a >> basic tenet of Wireshark use. There are millions of lines of code in >> Wireshark dissectors and they really shouldn't be given admin privs. >> >> Does anybody know whether there exists, in Windows: >> >> 1) an inter-process communications mechanism, either documented >> or reverse-engineered *and* likely to remain intact and usable from release >> to release and in future releases, over which a HANDLE can be passed; >> >> > DuplicateHandle - > https://msdn.microsoft.com/en-us/library/windows/desktop/ms724251(v=vs.85).aspx > > A HANDLE to what though, the handle types that can be duplicated with that > call are limited? > > If it's a socket HANDLE, then WSADuplicateSocket ( > https://msdn.microsoft.com/en-us/library/windows/desktop/ms741565(v=vs.85).aspx) > is used. This creates a structure that can be handed off to the target > process by some IPC mechanism. > > The IPC Mechanisms supported by Windows are listed here: > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx, > pipes are commonly used. I don't think there are issues with pipes between > a non-elevated process and an elevated one, but I haven't personally tried > that. > > > 2) a mechanism by which a non-privileged process can request that >> a subprocess be run with elevated privileges - presumably requiring either >> user consent or something else to indicate trust - with such an IPC channel >> established between the non-privileged process and the privileged process? >> > > A way to elevate a subprocess is via a call to ShellExecuteEx() setting > the lpVerb in the passed in SHELLEXECUTEINFO structure to "runas". See > http://blogs.msdn.com/b/vistacompatteam/archive/2006/09/25/771232.aspx. > > This will invoke UAC if enabled (a it should be). > > > >> >> UN*Xes that support libpcap generally have 1) in the form of UNIX-domain >> sockets (or, in newer versions of OS X, Mach messages, over which those >> newer versions of OS X support passing file descriptors), and probably have >> 2) in the form of, if nothing else, sudo or some GUI equivalent. >> >> The idea here is to have libpcap - and WinPcap, if the answers to those >> questions are both "yes" - invoke a *small* helper process to do what work >> needs elevated privileges to open capture devices, turn on monitor mode, >> change channels, etc., so that programs using those libraries do not >> *themselves* require elevated privileges. >> >> If the answer for the first question is "no", then do we have some way to >> run dumpcap with elevated privileges and have a pipe between it and >> Wireshark/TShark? >> > > That's what currently happens on Windows using a named pipe, without the > elevation though. > > > An interesting article on process elevation and IPC using named pipes between process with different security levels: http://www.codeproject.com/Articles/19165/Vista-UAC-The-Definitive-Guide -- Graham Bloice
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
