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

[packetmon]

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.

DropMyRights

[WalterGR]

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.

It's called WINE, and there are other ways

[leonbrooks]

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.

Ballsy!

[scott_karana]

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. ;)

Re:Filesystem Filter Driver

[nuzak]

> THIS IS THE RIGHT ANSWER.

No it isn't. Or at least it is the right answer for the wrong question. Filesystem controls are completely orthogonal to process permissions. He's not trying to just limit filesystem operations, he's looking at all operations. How is a filesystem driver going to affect whether you can open Port 12345 if your windowstation isn't on some trusted list? Or whether you can impersonate another user only if it's run app XYZ within the last X minutes (think sudo). He's trying to extend process security descriptors, which, as far as I know, is simply not in the design of Windows. Even source licensees like Symantec and Checkpoint have still had to rely on hacking in API hooks.