A Windows Alternative to Linux Security Modules?

Cliffe asks: "I am a PhD candidate preparing to implement a new security (access control) model. I have been reading about Linux's LSM (which allow security frameworks to be loaded) but I was unable to find documentation for a mechanism in MS Windows which allows every individual application's access to resources to be mediated; for example, to restrict each application's access to particular files or network protocols. Is this type of mediation possible in Windows? Virus scanners and firewalls likely utilize similar capabilities. Where can the documentation be found?"

Voila

Here are some that my help you get started:

User Access Controls [microsoft.com]

SANS Top 20 [sans.org] (worth reading)

Windows Server 2003 Security Guide [microsoft.com]

Overview of the Windows 2003 Server [microsoft.com]

You can migrate some of the administrative tools under Windows 2003 SMB server over to XP. But I'm under the assumption you're looking at things from a server perspective. As for firewalls, etc., you have to define if you want a true firewall as opposed to relying on Windows' shabby firewall. If so then I suggest you take a look at Juniper's Netscreen Elite 5X if you're a small business. I mention this instead of Checkpoint or others since I have used many and my best recommendation would be the Netscreen. This comes via way of having to migrate a slew of Checkpoint's along with Rainwall for management to Netscreen. Things were so shoddy with Checkpoint's IPSO, even Checkpoint wouldn't support the financial institute I was doing work for. This forced us to rethink our tools and after months worth of tiger team testing, we went with Juniper.

No standard API

As far as I'm aware, Windows doesn't have any standard API for that. Products like ZoneAlarm restrict access to resources by inserting hooks into the system in a relatively ad-hoc manner. (This is not a criticism of ZoneAlarm.)

Given Microsoft's claims about a strong focus on security in the forthcoming Windows Vista, perhaps it has an interface for security modules of the type you're suggesting.

It's called WINE, and there are other ways

You can then literally apply Linux's [linux.org.au] security modules to individual Win32 applications -- or to individual instances of the same Win32 application -- by running the Win32 app under WINE [winehq.com].

Or run WINE under a different OS (e.g. OpenBSD [openbsd.org]) or emulator if you want different security tools.

I've done this with/for a number of customers, & integrating the security manageability with a system which has no viruses or spyware to speak of has saved them each endless damage (and endless payments to recover from that damage).

I've also convinced other developers to make their applications portable -- which has instantly increased their productivity and their market, too, sloughing off obsolete dependencies -- and simply stopped running the users under Windows (or anything from MS). This particular tactic earns you much peace & security in one step.

well, kind of

Hey, the .NET framework has an implementation of this. It only works for managed code, and it isn't as granular. (I can't say I'm terribly knowledgable about pluggable security architectures). It's called Code Access Security [google.com]. I wish you well on your thesis.

Function hooks

Some nifty things are possible if you hook functions in the WinAPI (so all calls to that function would go through your function first). Your app could then put whatever restrictions on access it you wanted (you could hook file open functions, registry open functions, etc). Here's an interesting article I found, wasn't the one I was searching for tho: http://www.codeproject.com/system/hooksys.asp [codeproject.com] Here is an article that shows how to prevent processes from launching: http://www.codeproject.com/system/soviet_protector .asp [codeproject.com] This might not be precisely what you wanted (a bit hackish compared to what you seem to be looking for) but it would work.

DropMyRights

I don't know much at all about the subject, but check out DropMyRights [microsoft.com], by Michael Howard, a security guy at Microsoft.

DropMyRights is a very simple application to help users who must run as an administrator run applications in a much-safer context -- that of a non-administrator. It does this by taking the current user's token, removing various privileges and SIDs from the token, and then using that token to start another process...

It's basically sample code, rather than a full solution, but it might give you a starting point.

Also ask Google about the .Net Framework's security model - in particular "code access security." From here [microsoft.com]:

Code access security uses the location from which executable code is obtained and other information about the identity of code as a primary factor in determining what resources the code should have access to. This information about the identity of an assembly is called evidence... It is the responsibility of the code access security system in the runtime to map this evidence into a set of permissions, which will determine what access this code has to a number of resources such as the registry or the file system.

Cheers.

So innocent...

Tough luck dude. Learn to use and hack Linux. Really, it's quite enjoyable.

Do you insist on Windows? OK...

You will be doing what every anti-virus and copy-protection hack does: you will patch the system call table. Note that it is completely unsafe to undo this without a reboot. There are race conditions that can bluescreen the system if you try.

You can not support Win64. The system call table was hidden. Aw heck, if you're already this hacky and evil, you might as well scan memory to find something that looks like the system call table. Just look for an array of function pointers of the right size and in the right order, bearing in mind that some other hack may have hooked the system calls first.

So, system calls happen, and you track what they do. You'll have to duplicate many OS data structures or make many evil assumptions about the content of kernel memory. Track what each handle refers to, the state of that handle, etc.

See? No problem. Easy as pie. You can contribute to making Windows such a stable OS.

Best steps moving forward

I don't know of any public API.

1. You should talk to your advisor to see if he would have a problem if an NDA is required, since it could affect publishability.
2. You should be checking on the MS oriented technical lists and forums. You're talking about some very deep and complicated types of coding, and your run of the mill programmer or admin is not the best resource.

filesystem filter driver

For files it's relatively easy, just build a filter driver that gets to look at and modify all filesystem requests. You need an IFSKit for that (there's sort of a GNU one at http://branten.se/nt/ [branten.se]). I dunno about other calls, grab a copy of the DDK (there is one in the downloadable KMDF) and see what you can find.

Not built-in to Windows

Windows security is all about restricting access to files and objects with user- and group-oriented Access Control Lists (DACLs and SACLs). When a user/automated-process logs in they are given an authentication token representing their account and group memberships (even their password version/iteration), and that token gets passed around to all processes and threads they touch as tasks proceed. Some processes (such as IIS) run under special LocalSystem/LocalService/NetworkService accounts and are able to impersonate other user accounts before making certain API calls (such as to open a file or directory on behalf of a web-connected user). There's nothing built-in to Windows to limit access based on the applications/processes themselves.

That being said there are some things that do application/process oriented security. ZoneAlarm, for example, is a third party application that sits between the Winsock API and the connected network(s) (it's a Network Filter driver if I recall correctly): it intercepts Winsock create/open socket calls, looks up the caller's process_id and information and then compares that process's information against its own internal access control lists to determine whether or not a socket can be opened for listening or outgoing connections.

The .NET framework also has some application-oriented access controls, but again this is built on top of Windows itself.

Filesystem Filter Driver

To properly restrict access to files, you'll need to write a filesystem filter driver. This is how most antivirus programs work. More information here:

http://www.microsoft.com/whdc/driver/filterdrv/def ault.mspx [microsoft.com]

Writing a FS filter requires the IFSKit, which is expensive and does not come with an MSDN license. To filter network access, you would use a TDI filter driver. I don't know of any way of filtering calls to DeviceIoControl other than by hooking CreateFile and doing filtering there, unless there is a facility in the ifskit to fiter those "fake" filesystems.

Ballsy!

This guy sure has a lot of balls asking for (admittedly minor) thesis help on a site his faculty could be reading this very minute. ;)

good luck with it!

I certainly wish you the best of luck with it.
given the design of the windows core (kernel*) I am not
sure this can be implemented without a significant redesign. :(

Linux is pretty good at this, as is the NSA offering
(called SELinux). OpenBSD is far superior in this aspect.

there is one additional problems: M$ might decide to
"co-opt" your work on you if they like what it does. best
to be cautious with a shark like that.

You'd need to create a user for each process

To separate out like this, you'd need to have each program run as a different user, and not give that user any rights.

You can't run them as the normal user. Even if you remove all the privileges, it is still the same user SID (Windows's UID). By default, a process's ACL allows debug access for the same user. That is, if program A and program B run as the same SID, then by default process A can manipulate process B and vice versa. Thus, if you did this, the program could do NtWriteVirtualMemory on any other non-sandboxed process to inject code.

Windows Vista can separate users' processes into the normal and elevated security processes, but it does nothing to stop processes at the same level from manipulating each other.

Don't see it as a security flaw that Windows does this. It is simply following the access control list. (It's not just the ACL that matters. An owner of a kernel object may set the ACL regardless of the ACL, so as long as the owner SID remains the same the processes can manipulate one another.)

Melissa

Filesystem filter driver

A AC posted this earlier and it deserves a repost since it's the best answer I've heard so far.

To properly restrict access to files, you'll need to write a filesystem filter driver. This is how most antivirus programs work. More information here:

http://www.microsoft.com/whdc/driver/filterdrv/def ault.mspx [microsoft.com]

Writing a FS filter requires the IFSKit, which is expensive and does not come with an MSDN license. To filter network access, you would use a TDI filter driver. I don't know of any way of filtering calls to DeviceIoControl other than by hooking CreateFile and doing filtering there, unless there is a facility in the ifskit to fiter those "fake" filesystems.

MS Windows Internals, 4th Ed.

This book is awesome, takes you down into the deep caverns of hell that are the MS WinNT based OS.

Chapter 8 deals with security, and offers the following juicy nugget:

Security reference monitor

A component in the Windows Executive(\windows\system32\ntoskrnl.exe) that is responsible for defining the access token data structure to represent a security context, performing the security access checks on objects, manipulating privelages[...], and generating any resulting security audit messages.

Among others. This comes from a sections called security system components. There's about 40 pages to the security chapter and they take you from authentication checks(user enters password) to actually observing the OS change a privelage. I highly recommend this book, it goes really deep into the underlying archetecture of Windows; farther than many would care to go.For those that missed it, it's
MS Windows Internals, 4th Ed., Mark E. Rissinivich and David A. Solomon, ISBN# 0-7336-1917-4

Ask tzuk at sandboxie dot com

His working implementation is available at http://www.sandboxie.com/ [sandboxie.com]

Maybe he'd tell you in exchange for a redesign of his site.

Simplest Windows security measure

You know how, when you download a file with IE and try to open it on XP SP2, it asks you if you are sure because it's an unsigned executable every time? If you could just enable that for every executable by default, it would be almost impossible for a virus to get in. If you made it impossible for non-admin users to allow unsigned code, you would instantly improve security massively.

But I don't think it's possible in Windows.

Core Force

http://force.coresecurity.com/ [coresecurity.com] TCP/IP, File and Registery ACL's

Not a direct answer but...

Cisco Security Agent [cisco.com] is a close analog to the sort of comprehensive kernel security hooking that something like LIDS [lids.org] does on Linux. If you can do some research to determine how they're doing it, that'll be a start. They hook all sorts of things, from file and network opens to attempts to sniff keystrokes and executing dynamically modified memory.

Make Windows more secure than Linux

Core Force [coresecurity.com] is just such an application. From the about page:

CORE FORCE provides inbound and outbound stateful packet filtering for TCP/IP protocols using a Windows port of OpenBSD's PF firewall, granular file system and registry access control and programs' integrity validation. These capabilities can be configured and enforced system-wide or on a per-application basis for specific programs such as email readers, Web browsers, media players, messaging software, etc.

Basically, the way it works by default is much like ZoneAlarm. If an application hasn't been configured, you get an alert saying "XYZ.exe is trying to access 87.65.43.21... allow/deny?" And you have the option to add it as a permanent rule. Unlike ZoneAlarm, however, it's not an all-or-nothing option. You can choose to allow only outbound port 80 traffic to 12.34.56.0/24 from source port 10431 with certain TCP flags and on the 2nd network interface if you choose.

This also applies to the filesystem. Grant read/write/execute access anywhere from an entire drive, to directories, down to the individual file level. Choose whether or not permissions propogate to child files/directories. Ditto for the registry. As the about page describes, it's a powerful firewall for not just tcp/ip, but also for the filesystem and the registry.

I ran Core Force on my old machine and it was really interesting to watch just how many times Windows phones home. After a while, I just setup default deny rules for all Microsoft IP addresses. But damn if there wasn't a ton of background communication going on for all sorts of applications. It takes a while to get the configuration right and for trusted applications that you don't want to go through the hassle of configuration everything in minute detail (eg: games where you don't want to have a popup right in the middle of fragging someone), you can just assign it full rights to the system as if you're running without Core Force.
 

Quick Question

Do we all get a PHd as well if we help you? If so, can you please provide details of the institution issuing the doctorate - I want to make sure that I don't get a bad school added to my CV.

Core Force

i just read about CORE FORCE [coresecurity.com] in some other discussion, and this might be what you are looking for.

From their site:

CORE FORCE provides inbound and outbound stateful packet filtering for TCP/IP protocols using a Windows port of OpenBSD's PF firewall, granular file system and registry access control and programs' integrity validation. These capabilities can be configured and enforced system-wide or on a per-application basis for specific programs such as email readers, Web browsers, media players, messaging software, etc.

VMS

Interesting. If I recall, VMS has a security model in which applications had rights along with users. Kind of like setuid, but granular. I believe that a process's rights were the combination of the rights of the user and of the application.

Windows NT was designed and implemented by the main VMS designer. A lot of the low-level kernel stuff is quite similar. But I don't think this feature made it across in any way.

Linux or Windows..

Thank you all for your advice,

Ideally I would like to implement my access control / application confinement model on both Linux and Windows. Unfortunately time will most probably prevent that (at least during my current studies). Currently I am considering various implementation options.

Linux seams to be the natural choice: it has frameworks that are unlikely to drastically change any time soon, most access control and application confinement research is conducted on Linux, and ideally I would like to contribute open source to the Linux community.

On the other hand Windows may need improved security more than Linux: both models would benefit from improvements but Windows is used by many more people and thus the advantages would benefit more people right away. Also it is currently unknown if Vista will implement mediation of security differently and that may set back my implementation efforts.

Thanks again to everyone who replied. Slashdot really is a great place.

Cliffe.