Re: Windows: use low integrity level to restrict privileges?

[Guy Harris <guy () alum mit edu>]

On Jul 25, 2014, at 6:40 PM, Julien T <julien.t43 () gmail com> 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.)
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe