Sometimes It Seems Like Unix(*) Needs to Learn from Windows

(*) By “Unix”, I mean Linux, Unix, AIX, OS/X, and similar flavours.


Way back when, about twenty or so years ago, I was a Unix admin, and a Unix developer. I had to be both, because I was the only person in the company who could spell Unix.


My favourite game was to go along to presentations for Microsoft Windows ‘new features’ and say “Oh, but hasn’t Unix had that for the last twenty years?”


Sure enough, there were countless things that Windows users and developers were just discovering (TCP/IP, shared libraries, multiple sessions on the same computer) that had been in Unix for some time. Linux was yet to make a mention, but as I’ve moved firmly into the Windows world, and left Unix behind, I’ve pretty much assumed that technologically speaking, if Windows has it, Unix and the like must also have the same functionality.


As I re-engage with Unix and Linux developers and IT professionals in recent months, though, I can see that there are some areas – particularly in security – where Windows is far ahead of the *x operating systems. Here’s a few:


Where’s my EFS?
EFS, the Encrypting File System, is one of Windows’ best-kept secrets. It’s not really a secret, of course, but it acts like one – there are so few people willing to use it, and mostly because they’re scared of or don’t understand it.
EFS allows users (under administrative control and with appropriate recovery measures in place) to choose files to encrypt, and to declare which other users can access the encrypted files.
EFS-encrypted files are encrypted on disk, and the keys cannot be broken simply by mounting an offline attack, because the key for each file is encrypted with users’ public keys, and the private keys are held securely in the users’ certificate store.
What does *x have in response? Whole disk encryption by third-party products (OK, Windows has Bitlocker and any number of third-party products). EFS protects individual files, and is far more fine-grained than the ‘all or nothing’ access of WDE (or FDE, Full Disk Encryption, if you prefer).
Single Certificate Store
This isn’t really a “single” store so much as a predictable location for the certificate store. If you want to read a user’s certificates and keys, you know where to find them (although you generally only have access if you are the user in question. Private keys from the certificate store are protected using the DPAPI, appropriately protecting them (apart from some key recovery scenarios, you have to log in using the password associated with the keys).
Similarly, certificates and keys belonging to the system and its service accounts are also in predictable locations.
This makes life easy for tools that need to scan for certificates due to expire.
Where are certificates and keys stored in *x? All over the place. Generally in “PEM” files, usually (but not always) in the same directory in which the application that installs them is.
How are these private keys protected in *x? There’s sometimes a password to open up the private key from the PEM file, and usually the PEM file has a restrictive access mask on it. [Read further for more problems with this]
Single SSL Library
It’s not uncommon to see several instances of OpenSSL installed on any particular system, whether it’s *x or Windows, if the system runs applications that use OpenSSL.
Windows developers, of course, can simply use the SSL API built in to Windows (CryptoAPI, CAPI and SChannel), and not have to worry about shipping an SSL library with their application, or keeping up with new versions as they come out, or tracking down customers and notifying them of updates to address security flaws (such as the Debian Linux key generation flaw I posted about a while ago).
Single SSL Configuration
If I want to disable SSL v2, or ciphers with fewer than 128 bits, on Windows I can change a few registry settings and know that I’ve fixed every application that uses SChannel. I can even do that remotely, with remote registry editing from a script or group policy tattooing the registry.
To do the same for OpenSSL, it seems that I have to find every application that uses OpenSSL and change the configuration files there. 
Data Protection API and configuration file protection
This is the one that really started me on this article.
How do you store a password in a configuration file?
Yes, the ‘right’ security answer is “you don’t”, but that’s naive. The fact is that there are many instances wherein you have to store a password – to access and authenticate to a remote application, or (if you’re using OpenSSL) to open a password-protected PEM or PFX file in order to read out the private key.
On Windows, the Patterns and Practices team have documented how to do this – basically, you use the DPAPI to encrypt the password into the config file, and again to decrypt it back out – and your DPAPI keys are encrypted by your master key, which is derived from your password. The end result is that you can’t get those DPAPI keys without the password.
What do the *x platforms have?
”Put the password in plain text, and protect it with a restrictive access mask”, is what I’m told. And in a search, I couldn’t find anything better being recommended. OK, one person recommended encoding the password with base64, but that’s hardly a security measure.
Jesper brought up the excellent question of “how is it different?” – in the *x system, the password is marked as only being accessible to the correct user. I was about to answer him when Steve F spoke up for me, and noted that in the DPAPI case, you have to read the file, and then an API has to be called to decrypt the password; in the *x case, you simply have to read the file. There are many many more exploits that allow the reading of a file under privileged rights than there are exploits that allow the execution of code.
Patch Management and Group Policy
Microsoft has done a really good job of implementing enterprise-level management features into their operating systems, from Group Policy and WMI to WSUS and other update management tools.
The *x systems I’ve seen seem to be built from the perspective that each system has its own attendant administrator, who is only too happy to manually deploy patches or tweak settings in line with some policy on a scrap of paper or post-it.

Maybe I’m missing some huge advances, and maybe some of these issues are resolved with a third-party tool – but then, maybe that’s part of the problem too. All of the above are a part of the operating system in Windows, and can be relied on to exist by developers, and their use by applications can be expected by IT professionals.


[Disclaimer: Yes, I know there are still areas where Microsoft needs to learn from Unix and Linux, and perhaps it’d be good if you’d educate me on those, too. This isn’t a “Windows is better than *X” debate, it’s a “hey, even if you think *X is better than Windows, here are some areas *X needs improving in”.]


Edit: There have been some excellent comments posted overnight in response to this article, and as I had hoped, I am mostly still ‘in the dark’ about what Linux and Unix-like systems offers. I’ll be looking at these as I have time, and responding when I can. For now, just let me say that I am impressed to see so much technical content in the responses, and so little of the “fanboy” behaviour that often characterises these discussions.

16 Responses to Sometimes It Seems Like Unix(*) Needs to Learn from Windows

  • jhansonxi says:

    Is source code available for these Windows functions? They aren’t worth anything without it. All the “wonder cures” of the 1800s and 1900s disappeared when laws were enacted that required their ingredients to be listed. For most the only active ingredient was cocaine. So what are the active ingredients in Windows crypto? Are they worth anything or just marketing?

  • Sum says:

    > Where’s my EFS?

    There are at least a couple of options in linux. One is eCryptfs which allows to encrypt files as required. Other is EncFS which allows creating encrypted directories. Unlike EFS both have complete information in the files/directories themselves so that one can just copy those around without problems. In fact EncFS is particularly useful if you want security with services like Dropbox. I create a symlink to encrypted version of directory in the dropbox directory, and synchronize it. On any target computer I can create the same symlink, mount the EncFS directory with the same password and have all the data back.

    > Single Certificate Store

    True this is application dependent. However in linux most applications use some common location. For example, system wide certs for servers etc are in /etc/ssl/certs (for Debian and derivatives) while for GnuPG the keys are in $HOME/.gnupg and all apps that integrate with GnuPG use the same location.

    > Single SSL Library

    This is actually a bigger problem on windows than linux. In all linux distros there is a standard version of OpenSSL library that is maintained/updated by the package tools. On Windows, however, each application maintains its own version of the library. For many applications CryptoAPI is quite inadequate for a variety of reasons (e.g. for our application the PKCS#12 support was not good enough and interoperability with java certs was missing) and for such cases each app ends up installing their own version of library.

    > Single SSL Configuration

    See above regarding location of certificates.

    > Data Protection API and configuration file protection

    Applications can choose to use gnome-keyring (or kwallet for apps using KDE API). Most applications on linux nowadays do that (apart from exceptions like firefox which has this support being worked on, or pidgin which also has a project to add this support though the new IM empathy supports this out of box). A more generic way would be to just point configuration directories to an EncFS directory.

    > Patch Management and Group Policy

    Indeed patch management on modern linux distributions is a breeze and much more reliable than windows. So tell me how do you upgrade a third-party software on hundreds of windows machines? In linux nearly all software (including third-party) gets updated automatically with the repos provided by third-parties and for custom software setting up a repository is trivial. Our company, for example, uses a combination of apt-proxy and custom repo to achieve this for workstations.
    Updating group policy may be easier on windows, though RHEL provides nice tools for that particularly with the new PolicyKit. Check RedHat network satellite.

  • Martin Owens says:

    You are correct, your missing some big advances. I don’t know what version of “Unix” your using, but Unix isn’t Linux is it. They’re both Posix based and both follow the same sets of standards, but it’s hardly the same code base, projects or people involved.

    Full Disk Encryption: Yup, got that integrated into your installer? Of course.
    File based Encryption? Yup
    Single instance of OpenSSL, yep
    Group Policies: Yep
    “Patch Management”, package management of deb-diffs count as patches, technically. Although management over networks is possible and encouraged.

    And the reason you wrote the blog post, passwords in files:

    You just DON’T store passwords in files. You use a keyring. A password protected, encrypted, multi entry, configurable system of password management.

    Programmers storing passwords in files should be kindly issued P45s and boxes to put their stuff.

    You need to quit windows, just for sanities sake, it’s doing something bad to your exposure to technologies.

  • Nick says:

    As regards your first point I’ve been using opensuse 10.2 for the last couple of years and my home partition is encryted, an option built into opensuse at least.

  • Anon says:

    The “problem” is that windows is a unified operating system. A lot of these things you have to use a collection of 3rd party tools for in Linux. Due to their different disto systems, that is very challenging to change (basically you need a standards board about it in Linux, not the CEO saying “this is so”).
    Never the less, they are extremely good ideas to implement.
    I also want to add that whole disk encryption is paramount in many scenarios(. You can additionally implement specific file encryption if you want. Finally auto mounting encryption partitions (which is what most people implement) are pretty worthless.

  • oiaohm says:

    Lot of what you have hear is part a joke.

    Patch Management of Linux is done really simply. It called run you own update server that just happens to be normally http or ftp server. Then use a Host intrusion detection software to make sure they are installed while checking other things like tampered with files. So basically anti-malware and update system in 1. I know what one I would prefer having.

    Group Policy work in progress there are a few different solutions. The old school is called clone manage. All machines are just configured the same. rsync everything in the etc directory bar hardware related. More modern are under development like freeipa.

    Data Protection API basically covered by PAM. Linux does not have to store its passwords in files you can store them under what ever system you like. That is what PAM is about plugable auth system. So if you wanted to wrap shadow up in a encrypted file you could.

    The idea of PAM is quite wise compared to Data Protection API. Number one secuirty threw obsercuity. If you want to use something completely unique that a hacker has never seen before PAM provides you the way to plug it in.

    EFS can be done by cryptfs and other options under linux with the option for half key to only be accessible when connected to an approved network.

    EFS is crackable by a Offline attack. Just trick windows into allowing everyone to login without needing to enter a password. The hash is good enough to open up the encrypted storage.

    cryptfs using pam with half key storage one machine is powered off half the key is lost until its reconnect to approved network so protecting files.

    This is only the tip of the protected filesystem that can be done with Linux. There is a important reason for putting on protected files in the same folder. So you can use items like selinux to forbid applications accessing those files from putting data into swap or insecure temp files. Does it need better setup tools I will give you that.

    Wallets/keyrings(same file 2 different names) shared between Gnome and KDE are growing as single access storage.

    For SSL certificates normally running local CA and linking application to it is done.

  • rkk says:

    Don’t compare *nix with the rubbish windows! Windows has to learn a lot from *nix and not the other way around! First and foremost question to windows and it’s lovers is that: Are they ready to open source the windows kernel source code like linux kernel source code? They won’t and never will show-up their dirty code! Windows need to learn a lot from *nix!

  • Alexander says:

    Mr Jones,

    I am far from the thought that Windows is a piece of crap and that no decent idea could be borrowed from it, but I find the approach of addressing AIX, OS/X and Linux with the same set of critics pretty amusing. Let’s start point by point (I am not going to detail my answers as I don’t have the time and the will to go any more deeper):

    – Where’s my EFS?
    AIX supports EFS.

    -Single Certificate Store
    OS/X key manager.

    – Patch Management and Group Policy and Single SSL Library
    Just use any modern *x system with package manager.

    Regarding the other two points – sure, they sound nice and I guess someone more knowledgeable than me can point the exact *x approach to both these issues. I know that with Linux I have the freedom to compile OpenSSL without SSLv2 support – but there are many other solutions. It is curious, though, to look at the number of existing Registry cleaning applications. Believe me – not having to deal with the Registry hell outweighs the inconvenience to actually know which services are running on my system and be able to configure them.

    The DPAPI seems like a nice thing and I am curious to see which are the equivalent *x technologies.

    There are many bad design decisions that are still laying around today in the *x world (you may wish to check out the Unix Haters Book). However, the *x world has the freedom to experiment and adopt contradicting paradigms, which gives flexibility and eventually helps select the best solutions.

    Have a nice day!
    Alex

  • Brian says:

    Regarding EFS. I think Ubuntu has some sort of it, for example one can choose to have the whole home folder encrypted during OS installation.

  • Jubal says:

    Some points for further research (note, that most of these comes from my memory; what is amazing, that it’s still better than your – reportedly – researched article):

    1) EFS: FUSE + encfs
    2) single certificate store: ongoing work, both GNOME and KDE are providing mechanisms for it (and, hopefully, these will be unified)
    3) single SSL library: Not true on Windows side (i.e. even if system is providing the interface, programs are not always using it)
    4) single SSL configuration: see 2)
    5) depends, not my area of direct interest
    6) cfengine or puppet

  • Ben Measures says:

    > EFS-encrypted files are encrypted on disk, and the keys cannot be broken simply by mounting an offline attack, because the key for each file is encrypted with users’ public keys, and the private keys are held securely in the users’ certificate store.

    EFS is smoke and mirrors.

    Offline-attack (aka stolen-laptop attack):
    Copy the encrypted file(s). Copy the certificate store (in the user profile). Crack the user password (brute force/dictionary). Retrieve the EFS private key. Decrypt the FEK. Decrypt the file.

    Online-attack (aka ease-of-use attack):
    Email user a trojan. Trojan copies the file out, which is transparently decrypted by the OS.

    > EFS allows users (under administrative control and with appropriate recovery measures in place) to choose files to encrypt, and to declare which other users can access the encrypted files.

    These features provide more attack vectors:

    Crack other users’ passwords.
    Trojan other users.
    Attack recovery measures (anyone remember Windows 2000 and EFS?)

    > What does *x have in response? Whole disk encryption by third-party products (OK, Windows has Bitlocker and any number of third-party products). EFS protects individual files, and is far more fine-grained than the ‘all or nothing’ access of WDE (or FDE, Full Disk Encryption, if you prefer).

    “Teach users to never encrypt individual files but to encrypt folders. Programs work on files in various ways. Encrypting files consistently at the folder level makes sure that files are not unexpectedly decrypted.”
    Best practices for the Encrypting File System
    http://support.microsoft.com/kb/223316

    Applications don’t save directly to files if they value that data. They save to temporary files which are then copied over. These temporary files are not encrypted unless folder-level encryption is enabled on those containing folders.

    So this “feature” of file-level encryption is actually a liability.

  • dakira says:

    I haven’t used EFS, yet, but maybe ecryptfs ist, what you’re looking for.

    The location of certificates IS in fact predictable. Especially if you use an LSB Linux (which should be done in corporate environments).

    A lot of your points are understandable but one point is seriously wrong and that is “Patch Management and Group Policies”. Every major Linux vendor has pecific tools to do what you ask for (like Landscape from Canonical). And even without these tools it’d take a sysadmin half a day at most to implement something like WSUS using what’s offered by the debian package mangement.

    Nexenta offers even more by using ZFS as its default filesystem you can easily “undo” updates if – in spite of testing – they still don’t work under specific circumstances.

    DPAPI: there’s no single API for doing this but every app can use e.g. the gnome keyring (which is well encrypted and unlocked with the login-password). Depending on what you develop for there are several such solutions and AFAIK there are ways to automatically address the right (present on the system) one. At least others are doing it ;)

  • sbenson says:

    Debian has been mounting encrypted filesystems for a number of years. Is this not a competitor for EFS?

  • Kellito says:

    It’s a funny article. Completely bogus by the way. Linux has all the things, mentioned. And the thing that areportrayed as weaknesses are really advantages, _especially_ in security. And the proof: How many times you heard of compromised client linux machines? Bot nets? No thank you.
    If you dont like Linux, it is ok. The only thing I ask please get your facts straight.

  • Q-zar says:

    Actually Linux does have an encrypted file system…wait…it has several you can deploy on an entire file system or on a single file. Not to mention the fact that Windows EFS is fairly easy to decrypt if you hook the system while someone is using the encrypted file system (just another well known Windows problem – it doesn’t pass keys very well).

    Also group policy is a pretty much non-existent in Windows. Sure it has pretty buttons to manage whole servers with, but I’ve never seen Windows create a jailed session that can compare with Linux. Sure, with enough hair pulling and self mutulation you can get Windows down to near the same level, but you have to do 3-10 times as much work to get to do exactly what you want. SAY ‘ELLO TO MY LITTL’ FREIND – ROOT!

  • a joke says:

    Alun Jones …. r u stupid or practicing to be one?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>