Is Microsoft Windows quite secure (as secure as linux) if used properly?

The Novell AppArmor team no longer exists. They laid them off in 2007. The lead AppArmor developer (Dr. Crispin Cowan) was then snatched up by Microsoft and has been with them since. AppArmor development is now done by community volunteers (with some Canonical people helping out).

AppArmor doesn't really work that way. It is less of a sandbox and more of an access control system (a variant of a MAC to be exact). On Windows, you would call this a HIPS.

What you are describing is probably more closely analogous to a chroot jail. Chroot jails are often used on Linux (and other Unixes) to test stuff. They are built into the OS itself. However, one must be careful because chroot jails were not really created for security purposes. FreeBSD, on the other hand, has a variant of chroot that has been designed for security. Those are called BSD jails.

AppArmor is an access control which means it watches each and every detail of an application (much like a HIPS). First, you create a bare profile for the app, then let the app run. You then examine the log files to see exactly everything the app did and what exactly it needs access to in order to function. Then you whitelist those actions and blacklist the app from being able to do anything not specifically listed in its profile. This is essentially the principle of least privilege. So if the app is exploited, it wont be able to do anything not in the profile, which means the attacker will basically be "confined" by the profile of the app.

So, AppArmor doesn't really virtualize the app or anything of that sort. It doesn't even keep it from accessing the file system. What it does do is stop it from accessing any part of the file system not in the profile (principle of least privilege again). And, likewise, it doesn't allow it to interact with any other process or service not in the profile. You can think of it as being like AppLocker on Windows, except instead of whitelisting what apps can run, you are whitelisting what a running app can do (i.e. what files it can read/write and what processes it can spawn or interact with).

 

I am aware of Novell shutting down apparmor, don't mean its dead, there is an entire community of developers working on it and so is Canonical.

 

Indeed. Apparmor isn't dead - otherwise it wouldn't have been included in kernel 2.6.36.

 

Thats why I assumed apparmor was dead, my bad

 

I didn't say it was dead. I said in the next sentence that community development of AppArmor continues (with the help of Canonical).

 

In my experience (I am 10 years a Windows dev/admin and work alongside Linux dev/admins on the same big project) and from my general observations both operating systems can be secured down to similar levels to the point where the difference will not be due to differences in the systems but in the knowledge of the people configuring and maintaining those systems.
Quite often the details are not unique to one operating system or the other but common to both, especially in highly networked environments.

Cheers, Nick

 

For a mere home user like me, I think you may agree that Linux distros, like the 'Buntus, are less cumbersome to secure. One only optionally needs to enable apparmor on a fresh install and set allow/deny services/ports/ip adresses via an easy to understand gui (gufw). Anyway all I mean to say is that I find the two distros I use viz. Ubuntu & CentOS a pleasure to use and far less cumbersome to secure than previously my Windows XP with Returnil, Sandboxie, MBAM, Comodo FW and Avira AV etc. etc.

 

So do I and am a Unix vet and ex IBM programmer. Ubuntu makes it easy for me to spread linux and thats my sole mission now.

 

And thank heavens for that, find apparmor easier to implement than the overtly complex selinux.

 

And even those measures are normally not necessary but more or less paranoid. Having said that, I confess that I've enabled Apparmor, too.

Regarding the firewall

sudo ufw enable
sudo ufw default deny

is good enough for me - but actually superfluous on a desktop system, too.