Weekly Edition
Return to the Press pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Nine principles of security architecture (NewsForge)
NewsForge gives
an overview of some recommended security procedures that every systems
administrator should use.
"Security architecture is a new concept to many computer users. Users are
aware of security threats such as viruses, worms, spyware, and other malware.
They have heard of, and most use, anti-virus programs and firewalls. Many use
intrusion detection. Architectural security, though, remains a mystery to
most computer users."
(Log in to post comments)
Nine principles of security architecture (NewsForge) Posted Nov 23, 2005 17:39 UTC (Wed) by Zarathustra (guest, #26443) [Link] Paraphrasing Gordon Bell
"The cheapest, fastest, and most secure components are those that aren't there."
Code that doesn't exist has no bugs, has no security holes and most importantly: can't be used incorrectly.
Simplicity is the most important principle for building secure systems.
And people that thinks ACLs are a good idea should having nothing to do with building secure systems.
Nine principles of security architecture (NewsForge) Posted Nov 23, 2005 21:03 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link] >people that thinks ACLs are a good idea should having nothing to do with building secure systems.
Since you spake thus, Zarathustra, would you care to say why? Genuninely interested in hearing your rationale.
Nine principles of security architecture (NewsForge) Posted Nov 24, 2005 5:54 UTC (Thu) by Zarathustra (guest, #26443) [Link] ACLs not only add considerable complexity to the implementation of the system, but make the user interface for it many times more complex.In theory ACLs let you express much more complex security constrains, but that means that it's much more easier to make mistakes using them. Anyone can understand and remember the Unix security model of ugo/rwx, the rules to evaluate are very straightforward and due to it's simplicity it's hard to misuse. Compare that with ACLs where you can have dozens, if not hundreds of operations combined arbitrarily. The semantics are considerably much more hard to grasp and there are many more chances for bugs and for human errors. And the permissions system is not something just system administrators deal with, end users also have to understand it and it's implications. The biggest problem with the unix security model is suid, which is a huge backdoor, the second biggest problem is root, which is in a way another backdoor into the kernel security model. This two big mistakes were corrected in Plan 9; and a new simple, flexible and powerful tool was added: namespaces. Now linux has a rudimentary form of per-process namespaces(BSDs sadly not even that), but ironically it's the concept of root and suid that makes it's use extremely limited. Simplifying your model and removing special cases(eg., removing root and suid) can make your system both more simple and more flexible. ACLs are all special cases disguised in the name of 'flexibility'. Another example of simplification of security systems, this time in relation to authentication, can be seen in the factotum, in contrast with systems like PAM, it's interface is much simpler, easier to use and requires basically no configuration. (I will not comment on the evils of SELinux and friends as it has already been covered here by others more knowledgeable in the matter)
Nine principles of security architecture (NewsForge) Posted Nov 24, 2005 7:13 UTC (Thu) by Wol (guest, #4433) [Link] Ummm ....
The Unix model is an absolute pig if you want to allow an arbitrary groups of people to access arbitrary files on a many-users system. I may belong to several projects. I need to give project members access to files in their projects, but I wish to give some users access to my files that are not in their project, and keep other users away from my files, despite them needing project access. How do I do that in the old-fashioned nix model? Oh - assume I *don't* have root access to screw up the groups ...
The best system I ever worked on had ACLs. Very simple ones. Seven permissions, effectively rwx on files and directories, plus one allowing you edit permissions (PDALURW for those who recognise which OS :-) (They had to add an eighth, O).
And permissions WEREN'T additive. If your user was listed in the permissions list, that was what you got. If you weren't listed, you got the sum of your groups. And if your groups weren't listed you got the default (which defaulted to $NONE).
It's all trade-offs. The nix system may be simple, but it can't handle complex situations very well. Complex systems can't often handle simple situations well (I think SELinux falls in this category). This system was moderately complex, but moderately simple to use - a cinch in basic situations, but it could be a nightmare in very complex ones.
Cheers,
Nine principles of security architecture (NewsForge) Posted Nov 25, 2005 23:26 UTC (Fri) by flewellyn (subscriber, #5047) [Link] That sounds like TOPS-20. I've only been a tourist on the system at twenex.org, so I have to ask:did the system have a means of enforcing MAC, as well as DAC?
Nine principles of security architecture (NewsForge) Posted Nov 28, 2005 1:28 UTC (Mon) by Wol (guest, #4433) [Link] I presume you mean "mandatory" and "discretionary"?
iirc (it was ages ago), set a top-level ACL and it applied everywhere. So "discretionary" wasn't an option :-)
Cheers,
Nine principles of security architecture (NewsForge) Posted Nov 24, 2005 21:07 UTC (Thu) by jamesh (subscriber, #1159) [Link] The NT implementation of ACLs has the ability to set a file or directory to inherit it's parent's ACL.
With this flag, you can get away without setting an ACL on most files and directories -- an administrator might set the ACL on a users home directory, which will then get inherited by all files contained in it. Similarly, changing the ACL on the user's home directory will update the permissions of all files that haven't unset the "inherit ACL" flag.
So in this sense it can _reduce_ the complexity of a system, compared to traditional UNIX file permissions. Things aren't quite so black and white.
Nine principles of security architecture (NewsForge) Posted Nov 25, 2005 1:03 UTC (Fri) by Wol (guest, #4433) [Link] The NT system also has no (obvious) way of removing permissions.
If somebody has rights based on the group they are in, there is no (obvious) way of taking *some* of those rights away (of course, there's always the option of denying all access, but is that practical? :-)
I know there's some command-line option for reducing permissions, but I thought the whole point of Windows was that the command line was redundant :-)
Cheers,
Nine principles of security architecture (NewsForge) Posted Nov 25, 2005 3:26 UTC (Fri) by Zarathustra (guest, #26443) [Link] Yes, having to carefully dig thru the whole hierarchy of files to know what permissions will apply to a given file is such a great feature...
If ACLs are a bad idea, ACL 'inheritance' is even worse.
Nine principles of security architecture (NewsForge) Posted Nov 25, 2005 7:23 UTC (Fri) by mcm (guest, #31917) [Link] > Yes, having to carefully dig thru the whole hierarchy of files to know what > permissions will apply to a given file is such a great feature...
Re: inheriting acls:
Nine principles of security architecture (NewsForge) Posted Nov 25, 2005 7:53 UTC (Fri) by bk (guest, #25617) [Link] Transparency is a key goal of secure systems, no? Having to resort to a special tool just to understand the permissions on a given object is not transparent.
You better hope that tool doesn't have any bugs.
Nine principles of security architecture (NewsForge) Posted Nov 25, 2005 8:03 UTC (Fri) by Wol (guest, #4433) [Link] You better hope the OS doesn't have any bugs ...
Because the nix model doesn't have a tree structure (all inodes are independent, inodes can exist in multiple trees simultaneously) each object needs its permissions. In a tree-structured file-system it's not a problem.
But the unix system has its own problems - I link to a directory I want to crack, then trick the sysadmin into doing a "chown -R me" on ~me - viola I've just got access to your files :-)
Cheers,
Nine principles of security architecture (NewsForge) Posted Nov 25, 2005 8:31 UTC (Fri) by rfunk (subscriber, #4054) [Link] Wrong.Inodes cannot exist in multiple trees, and you cannot link directories in a way that would be followed by chown -R. Recursive commands like that do not follow symlinks, and the system won't let you create hard links to directories.
Nine principles of security architecture (NewsForge) Posted Nov 25, 2005 11:18 UTC (Fri) by dark (subscriber, #8483) [Link] ??You must have misthought there. You mentioned hardlinks, so you know that inodes can exist in multiple trees. You can link /etc/shadow into your own directory, and if the sysadmin does chown -R on it for you, you get the file. The main thing stopping this is that directories where users have write access (/var, /tmp, /home) are often on separate filesystems from the rest of the system. And of course that most sysadmins don't randomly chown whole directory trees.
Nine principles of security architecture (NewsForge) Posted Nov 27, 2005 5:38 UTC (Sun) by Zarathustra (guest, #26443) [Link] Both hard- and sym-links were hacks, and hacks that turned out to be a really bad ideas.
In Plan 9 you don't have them, but you have private namespace binds, so you can mold your namespace any way you like, but your changes can't affect others, and you can't trick others into doing what they don't want to.
Removing symlinks and hardlinks simplifies the file system model and has various security advantages, but still the greatest security improvements come from dropping suid and root.
Nine principles of security architecture (NewsForge) Posted Nov 24, 2005 13:46 UTC (Thu) by kune (subscriber, #172) [Link] These principles don't scale. A typical global enterprise operates today between 100 000 and 300 000 individual logical systems. Privately I have currently three computers, one WLAN router and server at a hosting service. Most enterprises and home users can't afford the effort to secure all the systems individually.
I still believe that a system, should be inherently secure. I still think it is a joke, that Windows XP SP2 requests from the user to install a Virus scanner to make it secure. It is like a car, that comes with a flashing light telling you to buy safety belts. I always wonder why companies have to invest so much, to operate their computing systems in a secure manner. Normally you would expect vendors to care for it. Windows needs nowadays a bunch of products to become enterprise ready (virus scanner, patch management, secure file transfer, etc.). The situation for Linux is much better, but you have to standardize on the distribution.
Economics will enforce scalable vendor-provided security. The question is, how long will it take.
Nine principles of security architecture (NewsForge) Posted Nov 24, 2005 15:18 UTC (Thu) by bk (guest, #25617) [Link] Installing a virus scanner won't make Win XP inherently secure; *fixing the security flaws* that the malware expoits will.
Extending your analogy, XP asking the user to install a virus scanner is like a flashing light on a new car telling the owner to buy a helmet because the airbags are expected to fail 50% of the time.
Nine principles of security architecture (NewsForge) Posted Nov 26, 2005 8:30 UTC (Sat) by mcm (guest, #31917) [Link] A virus scanner has nothing to do with exploitable security flaws in the OS, it is about executing possibly untrusted code. One solution is to have centralized databases signing the code (a la linux repositories, or ms certificates) and this works quite well. But sometimes you want to execute something that isn't available from a trusted source -- and that's where you need containment, and a virus scanner (or whatever you want to call it) that recognizes known badstuff(tm) is your first line of defense.
The containment part is important too, though -- and every distro really should have something along these lines on by default, e.g.: execute this as untrusted, oh it wants to access the filesystem, pop up a little notice or text prompt to give/deny permissions of that process, etc.
I know there's lots of addons to linux floating around, but things should be secure by default (at least for a distro aimed at the mythical JoeSixpack).
Nine principles of security architecture (NewsForge) Posted Nov 24, 2005 15:20 UTC (Thu) by dlang (subscriber, #313) [Link] the prinicpals scle very well, the particular implementation details that were mentioned in the article are aimed at admins of single machines, but the basic principals are the same ones you would use to secure a large network
The subway password story again Posted Nov 25, 2005 2:05 UTC (Fri) by dark (subscriber, #8483) [Link] I was a bit disappointed that the article trotted out the "people give their passwords to random interviewers on the subway" story again. From that story:
"When office workers were asked the same question outside a London subway station last year, 71 percent were willing to give up their password - just for a free chocolate bar."
I think a security professional should know better, and examine the real situation in that story. An interviewer offers you a chocolate bar in exchange for your password. The interviewer has no way to verify whether you tell him your actual password or something you just made up, but you get the chocolate bar either way. What do you do? What would 71% of the people do?
|
|||||||||||