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

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

On Jul 27, 2014, at 3:41 PM, Julien T <julien.t43 () gmail com> wrote:

> 2014-07-26 1:09 GMT-04:00 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.
>
> Of course, but many multi-platform applications try to improve their security be it chromium, firefox, adobe reader, 
> ...

We're not opposed to that, but using an OS-specific term such as "low integrity level", without indicating for the 
non-Windows developers what it is at the point at which you first mention it, is probably not the best thing to do.

And, yes, this would also apply to OS X developers talking about app sandboxes and entitlements:

        
https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AboutEntitlements.html

without describing them or, if similar things can be done there, talking about whatever SELinux or Capsicum or... offer.

> [1]

That's

        https://isc.sans.edu/diary/Limiting+Exploit+Capabilities+by+Using+Windows+Integrity+Levels/10531

which is talking specifically about the Windows integrity levels mechanism, which is, from that article, a mandatory 
access control mechanism assigning integrity levels to files and processes, with a process at a given integrity level 
prohibited from modifying files or processes with a higher integrity level, and with the default integrity level being 
"Medium", so that processes running with an integrity level of "Low" can't modify files by default.

> > Presumably you're referring to
> >
> >         http://msdn.microsoft.com/en-us/library/bb625964.aspx
>
> Yes, that's the parent article of the link I provided.

Yes, but

        1) footnote links are less noticeable than inline links (which is why I put the link in question inline)

and

        2) it just mentioned "A quick test with icacls [1]", which doesn't indicate that the link would explain the 
concept.

In any case, the bottom line is "no matter what platform you're using, don't assume all the developers or users will be 
familiar with it".

> > Or for a server using ReFS?
> >
> >         http://msdn.microsoft.com/en-us/library/windows/desktop/hh848060(v=vs.85).aspx
>
> AFAIK, ResilientFS fully supported NTFS ACL [2], so there should be no problem. can't test though.

That's

        
http://blogs.technet.com/b/askpfeplat/archive/2013/01/02/windows-server-2012-does-refs-replace-ntfs-when-should-i-use-it.aspx

and

        http://www.anandtech.com/show/5433/microsofts-refs-filesystem-for-windows-8-server-explained

However, none of the references indicate

        1) how integrity levels are implemented within the file system - if they're implemented separately from ACLs, 
then ReFS support for ACLs doesn't imply ReFS support for integrity levels

or

        2) whether SMBn, for various values of n, passes integrity levels over the wire

so they don't indicate whether stuff on a server would be protected.  *Presumably* Microsoft considers integrity levels 
important enough that they'd implement them in ReFS and SMB.

> Low integrity level seems a little investment (can do it per user install) for extra little security.

We're not going to run Wireshark, in its entirety, at low level, as it has to write files out, so that "little 
investment" would include the not-necessarily-so-little project of splitting dissection into a separate process.  That 
project may be worth doing, but "worth doing" doesn't, of course, necessarily imply "easy"....

> Win8 seems to offers more advanced mecanisms like AppContainer but not sure if it's possible outside of VisualStudio 
> [3]

The first link is

        http://msdn.microsoft.com/en-us/library/dn195768.aspx

which uses the unfortunate phrase "Windows Store", so I *VERY* sincerely hope that app containers do not, in any way, 
shape, or form, require that the program be written in a language or use a run-time environment that uses a large 
amount of Microsoft-patented technologies (no, Mono isn't good enough unless we can be *guaranteed* that we can write 
GPLed managed code that will be able to run on all current UN*X platforms without fear of patents and without "oh, 
sorry, the JIT only works on these processors, I guess you Linux-on-$ARCHITECTURE folks will have to live with an 
interpreter").

The second link is

        http://blog.nextxpert.com/2013/01/31/demystifying-appcontainers-in-windows-8-part-i/

which seems to be suggesting that you're not forced into Microsoft's "gosh, why *wouldn't* you want your desktop apps 
taking over the entire screen?" UI or into CLR-based languages in order to run an app in a container, but it does say 
Microsoft don't appear to be making it easy to avoid the Windows Runtime or whatever they're calling it if you want to 
run your app in  a container.

It also suggests that it occupies the same rough environmental niche as OS X's app store sandboxes:

        
https://developer.apple.com/library/mac/documentation/security/conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html

The third link:

        https://news.saferbytes.it/analisi/2013/07/securing-microsoft-windows-8-appcontainers/

gives some gory details; the fourth and fifth links:

        http://arstechnica.com/information-technology/2012/10/better-on-the-inside-under-the-hood-of-windows-8/

        http://recxltd.blogspot.ca/2012/03/windows-8-app-container-security-notes.html

give some more information.

That might be interesting (perhaps more so than OS X sandboxing, if the latter is available only to App Store apps).

I presume there's some equivalent to OS X's Powerbox:

        
https://developer.apple.com/library/mac/documentation/security/conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html

to let the File -> Open menu open whatever file the user requests.  That might be trickier for command-line apps such 
as TShark, though, unless either cmd.exe or PowerShell arrange that access to every pathname you type on the command 
line be granted to the program to which they're passed.

> > 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.
>
> I don't think 1.0 it's age ago.

It doesn't date back to the Middle Ages, but 6 years is "ages ago" in Internet time:

        http://www.wireshark.org/news/20080331.html

so I *do* consider it "ages ago".

> > (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.
>
> agree.

That might also mean that we wouldn't need to have the entire capture process run in a separate process (which has some 
of its own problems, namely that capturing can run significantly ahead of dissection, which causes some real ugliness 
when trying to stop a capture, for example).  Unfortunately, that would only work on OS versions with the Shiny New 
Privilege-Separated Pcap Library.

> > 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.)
>
> of course, there is [4]. I would be surprise any modern OS has not.

And for the benefit of those of us who prefer inline links to footnotes, that's

        http://msdn.microsoft.com/en-ca/library/windows/desktop/aa365574(v=vs.85).aspx

That link, however, doesn't say anything about sending HANDLEs over local IPC mechanisms; I didn't say "I don't know 
whether Windows supports any local interprocess communication mechanisms", I said "I don't know whether Windows 
supports sending HANDLEs or anything such as that over any local interprocess communication mechanism".  See, for 
example:

     Any valid descriptor may be sent in a message.  The file descriptor(s) to
     be passed are described using a struct cmsghdr that is defined in the
     include file <sys/socket.h>.  The type of the message is SCM_RIGHTS, and
     the data portion of the messages is an array of integers representing the
     file descriptors to be passed.  The number of descriptors being passed is
     defined by the length field of the message; the length field is the sum
     of the size of the header plus the size of the array of file descriptors.

     The received descriptor is a duplicate of the sender's descriptor, as if
     it were created with a call to dup(2).  Per-process descriptor flags, set
     with fcntl(2), are not passed to a receiver.  Descriptors that are await-
     ing delivery, or that are purposely not received, are automatically
     closed by the system when the destination socket is closed.

from the OS X UNIX(4) man page, which I think comes from the 4.4-Lite UNIX-domain socket mechanism and should be 
present in all 4.4-Lite derivatives, or

    Ancillary messages

       Ancillary data is sent and received using sendmsg(2) and recvmsg(2).
       For historical reasons the ancillary message types listed below are
       specified with a SOL_SOCKET type even though they are AF_UNIX
       specific.  To send them set the cmsg_level field of the struct
       cmsghdr to SOL_SOCKET and the cmsg_type field to the type.  For more
       information see cmsg(3).

    SCM_RIGHTS

              Send or receive a set of open file descriptors from another
              process.  The data portion contains an integer array of the
              file descriptors.  The passed file descriptors behave as
              though they have been created with dup(2).

from the Linux UNIX(7) man page and so on (other UN*Xes may do this 4.3BSD-style rather than 4.4BSD-style; there 
appears to have been a change).

Perhaps you can do that with the low-level IPC mechanism of NT, but that's not a documented API, and Microsoft might 
well choose to change it from release to release in incompatible ways.

> > 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.
>
> yeah, but on modern OS, javascript or activex are done in low integrity process be it for chromium or internet 
> explorer

I wasn't saying that code was safer and didn't need to be run in sandboxed processes; I was saying that it's *less* 
safe, in some sense, namely that it comes from the Intertubes and should be presumed untrustworthy and malicious unless 
proven otherwise.

If the dissectors

> > 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.)
>
> yes, but hopefully will happen. I still think than it's on a longer term roadmap than user security.

"Is", or "should be"?

Neither it nor separating dissectors into a separate process have positions on the roadmap right now.  If separating 
dissectors into a separate process is straightforward, it should probably be put on the roadmap, but I'd like to see 
minimizing the need to write executable code (in any language, including Lua) in order to dissect protocols arrive as 
soon as possible.

> [5]
> http://msdn.microsoft.com/en-us/library/bb625962.aspx

Another subpage of the MSDN "Windows Vista Integrity Mechanism Technical Reference" link I posted.

> http://msdn.microsoft.com/en-us/library/ie/dn519894(v=vs.85).aspx

A discussion of ActiveX controls in IE when it's using the integrity mechanism and app containers; presumably of 
relevance to plug-in dissectors.

___________________________________________________________________________
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