1: Take advantage of the keyring
Unix security ? inherited by Linux ? was developed in a friendly academic environment and for a single machine only. Hence, with no built-in notion of a networked environment this is what you get: Kludges and inconvenience. Compare to Windows which was built with multi-users and networks in mind: Authorization *and* credentials are manageable across multiple machines and domains.
A Linux user can be member of a single group only. A file can have a single owner and belong to single group only. If you want to access a file which belongs to a different group from yours, you are out of luck. Either change the group of the file (but locking out users from the current group), change the user?s group (but user loses access to files in his current group) or (eureka!) change the file?s permission so that everyone in the world can access it.
Windows users can be members of any number of groups. Files access control lists can allow any number of users and/or groups fine-grained access.
Sure, you can bolt on ACLs on Linux. But hardly anyone does it. Why? Because it is a kludge which have all kinds of corner cases and in general works horribly across the network.
2: Enforce user password update
False sense of security! If you set up a draconian policy users will just change a few components and will thus use predictable/guessable passwords. Or worse, they?ll keep a note in their drawer with their current password.
3: Don?t blindly disable SELinux
Again, Unix and Linux lacks fine-grained security. This goes for the file system where you only have me-us-everyone levels with only read/write/execute permissions. But it is even worse: Practically nothing else is securable. If you cannot ?map? your object to a file system object it is not securable, period. You cannot secure an API using permissions.
Windows has granular permissions for e.g. desktops, windows stations at API level. This means that with Windows you can associate permissions with roles/groups and have fine-grained (and policy driven) control.
The Linux solution? Setuid and setgid. Two swiss cheese horrors which are open invitations to hackers! Why? Because these two gems will execute a file as the file owner/group instead of the launching user. With setuid/-gid you can design an executable which assumes that it runs as root (because it will). But what happens when the utility has a buffer overflow? Pwnage! Think this is theory? Think again, history is littered with vulnerabilities in setuid utilities: http://www.bing.com/search?setmkt=en-US&q=setuid+vulnerability.
4: Don?t log in as root
Duh!
5: Install security updates quickly
But I thought that Linux didn?t have any vulnerabilities? It does? But at least it has fewer vulns than Windows, right?
Wrong. Linux (the kernel) requires many more patches than Windows. Compare Linux kernel 2.6 with Windows Vista:
http://secunia.com/advisories/product/2719/
http://secunia.com/advisories/product/13223/
Linux kernel: 417
Windows Vista: 183
This is actually a bit unfair as the Vista numbers include vulnerabilities in bundled software such as Outlook Express, Movie Maker, Speech Recognition, Malware Protection Engine etc.
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
