4 ms·

"The Unix Design is significantly less granular than Windows..." That's why it's more secure. Complexity means you don't know what's going on. Complexity means

by api 15y ago

"The Unix Design is significantly less granular than Windows..." That's why it's more secure. Complexity means you don't know what's going on. Complexity means you will forget something. Complexity means there's more likely to be a way to squeeze through, more likely to be a bug, more likely to be a little thing that is forgotten. This is also a problem with complex cryptographic APIs, overly complicated things like PKCS11 and X.509, etc. It's curious that security-related systems are among the most complex, since complexity is inherently bad for security. I call it a lack of "situational awareness."

nwmcsween 15y ago
Unix by far is not secure. Access control via unix permissions is a mess, this is why we have selinux, apparmor, smack... The whole 'complexity' argument is moot todays unix with selinux, chrooting, jails, apparmor is much more complex than say a capability based security.
- X-Istence 15y ago
  ACL's are not even close to what selinux, apparmor, and smack are trying to accomplish.
  - nwmcsween 15y ago
    I never said anything about access control lists
- Hawramani 15y ago
  Can you mention specific issues with Unix permission management that Windows solves?
  - Goladus 15y ago
    One example: given a file, you can create several different access levels. One group can be read-only, one group can have read and write but NOT delete, one group might only be able to modify permissions, and one group might have full access to the file, while "EVERYONE" has no access at all. Administrators, incidentally, need not have access beyond "take ownership" which is an obvious and easily-audited action. These are all standard features in most ACL-based multi-user environments. Unix file permissions don't use ACLs, so off the top of my head I'm not sure how you would set this up on Unix. For one thing, I am pretty sure w implies delete permissions. So that group can't even exist, and if it could, there's no easy way to have that group be different from the read-only group, and still have a no-access-at-all group. I suspect most complicated requirements can be resolved with some combination of sudo and traditional permissions but it's not always straightforward and probably won't be exactly equivalent to the way you would do it in Windows.
    - Lexarius 15y ago
      The old standard file permission system is the default on most unixy systems because it's easy to use and understand (more or less). That doesn't mean these systems don't have ACLs. http://linux.die.net/man/5/acl http://linux.die.net/man/5/acl
      - Goladus 15y ago
        I would say it's because that's conventional, it's what users expect, it's what many applications expect perhaps most importantly having ACLs is just not that important. It's not necessarily that it's "easy to use an understand." In Windows, it's there by default. I'm not claiming that windows is better or more secure, I am simply answering the question that was posed.
      - uriel 15y ago
        > The old standard file permission system is the default on most unixy systems because it's easy to use and understand And that is exactly what makes it more secure than ACLs which are extremely complex and unwieldy to setup and manage.
    - X-Istence 15y ago
      And those ACL's are available within OS X as well, as well as within Linux, Solaris, FreeBSD (UFS2 and ZFS). This complaint doesn't hold water. Those features are available within standard Unix environments (Solaris probably counts the most as a real Unix, OS X is technically certified Unix as well!). So Unix file permissions can use ACL's. The default is POSIX file permissions but they aren't the only ones available.
      - Goladus 15y ago
        It's not a complaint, it's just the way it is. The windows (NTFS and later) default security model uses ACLs. Unix doesn't. This gives windows a few minor advantages. Yes, of course you can do ACLs on Unix. If you really need them there are plenty of ways to do it. But the limitation I described is, nevertheless, a limitation of the default unix permissions model. It's mostly pointless to debate whether one is "better" than the other. There are advantages and disadvantages to both approaches, and it's trivial to screw up permissions either way. The biggest advantage of unix permissions is the culture and history surrounding them, as well as the design and conventional use of the system itself. On unix, application developers, maintainers and administrators have a pretty good idea about how permissions should be set. Generally, the need to run as root is fairly well quarantined to system administration tasks. It's not perfect, but it's much better than what I remember of windows, and a quick search suggests the situation hasn't much improved. Here's a user who discovered a problem using visual studio, he was able to solve it by running as Administrator: https://crmbusiness.wordpress.com/2011/05/12/gotcha-visual-studio-must-be-run-as-administrator-in-windows-7/ https://crmbusiness.wordpress.com/2011/05/12/gotcha-visual-s... If a unix OS were to abandon too much of the conventional unix way of setting permissions (regardless of whether ACLs are used or not), you could begin introducing similar problems.
jbjohns 15y ago
I'm sorry but this is a horrible argument. Granular security is critical to having a system that can actually be locked down. Which is why SELinux support is built into the kernel now.
- danudey 15y ago
  And from my experience, most admins turn it off immediately rather than rewriting security policies so that Apache can access data outside of /var/www/, etc. Sure you could modify the policy, but it's enough of a hassle that no one I know has ever done it. Restrictive security that just gets in people's way is terrible security. Just like forcing people to change their password every 14 days results in people using the same password repeatedly and incrementing a digit on the end (or writing the password down and sticking it on their monitor), creating overly complex rules means that people who absolutely must deal with these things (or who have the time) do so, and everyone else just turns it off and forgets it ever existed.
  - __david__ 15y ago
    I'm glad I'm not the only one that hates SELinux. I find its setup to be super complicated yet all it ends up doing is stuff that I can do anyway with native unix permissions. As best I can tell it's a completely parallel world that is just there in case you mess up your normal permissions.
    - jbjohns 15y ago
      You admit that you don't understand SELinux so could it be that you hate it because you don't understand it? The fact is there are a lot of things that SELinux makes easier. In SELinux you have your services run in contexts and you can say what they can do (e.g. can listen on port 80 but not make outgoing connections, etc.). You no longer have this ridiculous need to run as one user (root) and switch to another. Unix security is so simple that, for my tastes, it's actually more complex to set up securely than SELinux. If you use a distro that supports it SELinux is drop dead simple anyway.
- 15y ago
pnathan 15y ago
This is a good point. Getting ACLs to work - really and truly work in such a manner that they aren't overly restrictive or overly relaxed - is not trivial. If you can attain security by trivial actions... that's a lot better than having to be really clever about it.
- bborud 15y ago
  I discovered ACLs on some flavor of UNIX in the 1990s and tried to play with ACLs for a while. What I found was that a granular approach to security simply does not work for anything but trivial scenarios because of the amount of state that needs to be understood and managed. It turned out that in order to manage ACLs efficiently I would need additional tools to keep track of all the state and to discover potential problems in the configuration. The tools that came with the OS were not much help. Also, it took quite a while to communicate how the ACLs were set up, and why, to my colleagues. I've always found compartmentation to be a far better strategy than granular control. Mostly because it means you can reason about a system at a much higher level and you do not need to keep a lot of knowledge about state in your head while doing so. In fact, on most well-run UNIX systems I have seen, compartmentation seems to be the dominant strategy for managing security. The simplest form of which is to assign different users to different subsystems and to restrict access to these users as much as possible. For instance, if you run a database, you create a user owning all the data files managed by the database. You then, very selectively expose only what is needed to interact with the database to other users. (Interestingly you usually do not let the database user own the binaries since there is no need for the database user to manage these files). On various UNIXen, tools for offering compartmentation have been around for quite a while. Ranging from various forms of "jails" all the way to running virtual machines. I've even been involved in running a startup that sought to harden the Linux kernel in various ways to provide some tools to make compartmentation better (although this was never any sort of commercial success -- we ended up finding success in entirely different areas :-) ) My experience with operating systems and security is that it is extremely hard to make something that is both secure and user friendly. I do not expect operating systems that are appropriate for general consumer use to become particularly secure any time soon. We make security sacrifices because quite frankly we don't know how to reconcile these problems. It is also my experience that anyone claiming that OS A is inherently more secure than OS B is usually full of shit. In particular, anyone claiming the opposite of what empirical knowledge suggests, is a moron. Empirical knowledge seems to suggest that there is more malware and more problems with malware on Windows than any other OS, thus the statement that Windows should somehow be more "secure" is pure nonsense. Yes, it may present a larger target and more effort may have gone into making windows more secure, but to claim that it IS effectively more secure is, to be quite frank, a little bit insulting since it is a departure from observable reality. Note that I am not saying that Linux or OSX or FreeBSD is inherently more secure than Windows, but I will say that I think the traditional way of reasoning about security in UNIX environments is a lot simpler than in Windows environments. And simplicity is extremely important in security.

by api 15y ago

nwmcsween 15y ago

Unix by far is not secure. Access control via unix permissions is a mess, this is why we have selinux, apparmor, smack... The whole 'complexity' argument is moot todays unix with selinux, chrooting, jails, apparmor is much more complex than say a capability based security.

X-Istence 15y ago
ACL's are not even close to what selinux, apparmor, and smack are trying to accomplish.
- nwmcsween 15y ago
  I never said anything about access control lists
Hawramani 15y ago
Can you mention specific issues with Unix permission management that Windows solves?
- Goladus 15y ago
  One example: given a file, you can create several different access levels. One group can be read-only, one group can have read and write but NOT delete, one group might only be able to modify permissions, and one group might have full access to the file, while "EVERYONE" has no access at all. Administrators, incidentally, need not have access beyond "take ownership" which is an obvious and easily-audited action. These are all standard features in most ACL-based multi-user environments. Unix file permissions don't use ACLs, so off the top of my head I'm not sure how you would set this up on Unix. For one thing, I am pretty sure w implies delete permissions. So that group can't even exist, and if it could, there's no easy way to have that group be different from the read-only group, and still have a no-access-at-all group. I suspect most complicated requirements can be resolved with some combination of sudo and traditional permissions but it's not always straightforward and probably won't be exactly equivalent to the way you would do it in Windows.
  - Lexarius 15y ago
    The old standard file permission system is the default on most unixy systems because it's easy to use and understand (more or less). That doesn't mean these systems don't have ACLs. http://linux.die.net/man/5/acl http://linux.die.net/man/5/acl
    - Goladus 15y ago
      I would say it's because that's conventional, it's what users expect, it's what many applications expect perhaps most importantly having ACLs is just not that important. It's not necessarily that it's "easy to use an understand." In Windows, it's there by default. I'm not claiming that windows is better or more secure, I am simply answering the question that was posed.
    - uriel 15y ago
      > The old standard file permission system is the default on most unixy systems because it's easy to use and understand And that is exactly what makes it more secure than ACLs which are extremely complex and unwieldy to setup and manage.
  - X-Istence 15y ago
    And those ACL's are available within OS X as well, as well as within Linux, Solaris, FreeBSD (UFS2 and ZFS). This complaint doesn't hold water. Those features are available within standard Unix environments (Solaris probably counts the most as a real Unix, OS X is technically certified Unix as well!). So Unix file permissions can use ACL's. The default is POSIX file permissions but they aren't the only ones available.
    - Goladus 15y ago
      It's not a complaint, it's just the way it is. The windows (NTFS and later) default security model uses ACLs. Unix doesn't. This gives windows a few minor advantages. Yes, of course you can do ACLs on Unix. If you really need them there are plenty of ways to do it. But the limitation I described is, nevertheless, a limitation of the default unix permissions model. It's mostly pointless to debate whether one is "better" than the other. There are advantages and disadvantages to both approaches, and it's trivial to screw up permissions either way. The biggest advantage of unix permissions is the culture and history surrounding them, as well as the design and conventional use of the system itself. On unix, application developers, maintainers and administrators have a pretty good idea about how permissions should be set. Generally, the need to run as root is fairly well quarantined to system administration tasks. It's not perfect, but it's much better than what I remember of windows, and a quick search suggests the situation hasn't much improved. Here's a user who discovered a problem using visual studio, he was able to solve it by running as Administrator: https://crmbusiness.wordpress.com/2011/05/12/gotcha-visual-studio-must-be-run-as-administrator-in-windows-7/ https://crmbusiness.wordpress.com/2011/05/12/gotcha-visual-s... If a unix OS were to abandon too much of the conventional unix way of setting permissions (regardless of whether ACLs are used or not), you could begin introducing similar problems.

jbjohns 15y ago

I'm sorry but this is a horrible argument. Granular security is critical to having a system that can actually be locked down. Which is why SELinux support is built into the kernel now.

danudey 15y ago
And from my experience, most admins turn it off immediately rather than rewriting security policies so that Apache can access data outside of /var/www/, etc. Sure you could modify the policy, but it's enough of a hassle that no one I know has ever done it. Restrictive security that just gets in people's way is terrible security. Just like forcing people to change their password every 14 days results in people using the same password repeatedly and incrementing a digit on the end (or writing the password down and sticking it on their monitor), creating overly complex rules means that people who absolutely must deal with these things (or who have the time) do so, and everyone else just turns it off and forgets it ever existed.
- __david__ 15y ago
  I'm glad I'm not the only one that hates SELinux. I find its setup to be super complicated yet all it ends up doing is stuff that I can do anyway with native unix permissions. As best I can tell it's a completely parallel world that is just there in case you mess up your normal permissions.
  - jbjohns 15y ago
    You admit that you don't understand SELinux so could it be that you hate it because you don't understand it? The fact is there are a lot of things that SELinux makes easier. In SELinux you have your services run in contexts and you can say what they can do (e.g. can listen on port 80 but not make outgoing connections, etc.). You no longer have this ridiculous need to run as one user (root) and switch to another. Unix security is so simple that, for my tastes, it's actually more complex to set up securely than SELinux. If you use a distro that supports it SELinux is drop dead simple anyway.
15y ago

pnathan 15y ago

This is a good point. Getting ACLs to work - really and truly work in such a manner that they aren't overly restrictive or overly relaxed - is not trivial. If you can attain security by trivial actions... that's a lot better than having to be really clever about it.

bborud 15y ago
I discovered ACLs on some flavor of UNIX in the 1990s and tried to play with ACLs for a while. What I found was that a granular approach to security simply does not work for anything but trivial scenarios because of the amount of state that needs to be understood and managed. It turned out that in order to manage ACLs efficiently I would need additional tools to keep track of all the state and to discover potential problems in the configuration. The tools that came with the OS were not much help. Also, it took quite a while to communicate how the ACLs were set up, and why, to my colleagues. I've always found compartmentation to be a far better strategy than granular control. Mostly because it means you can reason about a system at a much higher level and you do not need to keep a lot of knowledge about state in your head while doing so. In fact, on most well-run UNIX systems I have seen, compartmentation seems to be the dominant strategy for managing security. The simplest form of which is to assign different users to different subsystems and to restrict access to these users as much as possible. For instance, if you run a database, you create a user owning all the data files managed by the database. You then, very selectively expose only what is needed to interact with the database to other users. (Interestingly you usually do not let the database user own the binaries since there is no need for the database user to manage these files). On various UNIXen, tools for offering compartmentation have been around for quite a while. Ranging from various forms of "jails" all the way to running virtual machines. I've even been involved in running a startup that sought to harden the Linux kernel in various ways to provide some tools to make compartmentation better (although this was never any sort of commercial success -- we ended up finding success in entirely different areas :-) ) My experience with operating systems and security is that it is extremely hard to make something that is both secure and user friendly. I do not expect operating systems that are appropriate for general consumer use to become particularly secure any time soon. We make security sacrifices because quite frankly we don't know how to reconcile these problems. It is also my experience that anyone claiming that OS A is inherently more secure than OS B is usually full of shit. In particular, anyone claiming the opposite of what empirical knowledge suggests, is a moron. Empirical knowledge seems to suggest that there is more malware and more problems with malware on Windows than any other OS, thus the statement that Windows should somehow be more "secure" is pure nonsense. Yes, it may present a larger target and more effort may have gone into making windows more secure, but to claim that it IS effectively more secure is, to be quite frank, a little bit insulting since it is a departure from observable reality. Note that I am not saying that Linux or OSX or FreeBSD is inherently more secure than Windows, but I will say that I think the traditional way of reasoning about security in UNIX environments is a lot simpler than in Windows environments. And simplicity is extremely important in security.