On Jul 25, 2014, at 6:40 PM, Julien T <julien.t43@xxxxxxxxx> wrote:
> As I'm back to use more Windows, I checked about privileges/sandboxing and I ask myself why not use low integrity level (like browsers).
Note that Wireshark is not a "Windows application", it's a multi-platform application for platforms including but not limited to Windows, so a concept particular to some platform might not be familiar to all developers or users.
Presumably you're referring to
http://msdn.microsoft.com/en-us/library/bb625964.aspx
> A quick test with icacls [1] got me running fine at low integrity level, checking just a few options. An extra point, it supposes a ntfs partition, no good for PortableWireshark on vfat usb.
Or for a server using ReFS?
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848060(v=vs.85).aspx
> Ideally a two (or three) process separation would be done to handle user gui / dissectors & misc / admin capture and to be integrated in the executable.
>
> I check the roadmap [2] and Privilege Separation for Unix and Windows are mentionned but I'm unsure if they were fully implemented for 1.0 or still work in progress? (3 process separation as said previously)
3 processes? No.
2 processes, as per "At a minimum, the capture role should be separated out." at
http://wiki.wireshark.org/Development/PrivilegeSeparation
Yes, we did that ages ago, on all platforms.
(Another interesting separation, at least on UN*X, might be to split libpcap into a library that reads packets and a separate program that handles all the operations that require privilege, such as opening a capture device, turning on monitor mode on some platforms, setting the Wi-Fi channel on some platforms, etc., so that the library either connects to a daemon running that program or runs a privileged version of that program, and that program hands the library a file descriptor from which it can read or which it can memory-map.
I don't know whether Windows supports sending HANDLEs or anything such as that over any local interprocess communication mechanism, as most if not all UN*Xes do. If so, then this could be done on Windows as well.)
The main reason to separate the UI and the dissection, at least as I see it, is that dissection is mostly done by C code generated by humans. It's not code downloaded from the Internet, so it's not *quite* as untrustworthy, in some sense, as, for example, JavaScript - or ActiveX - code downloaded from the Internet, so that you can *somewhat* believe it has no malicious intent, but, as it's C code, it's potentially more hackable than JavaScript code.
It might be interesting to see how much security could be improved by using protocol descriptions written in declarative languages such as ASN.1 or some DCE RPC IDL or some CORBA IDL or ONC RPC's rpcgen or X11's protocol description language or the WSGD language:
http://wsgd.free.fr
or... rather than C code.)
