| |||||||||||||
Access Control: take them from Novell NetwareAccess Control: take them from Novell NetwarePosted Nov 18, 2010 8:03 UTC (Thu) by zmi (guest, #4829)Parent article: Ghosts of Unix past, part 3: Unfixable designs
It's always very amusing to read about problems with permissions and ACLs within Unix and Windows. I cannot understand why developers don't look at the model Novell developed for their Netware systems in the 1980's already.
In Netware, you could quickly define an unlimited number of users/groups to a dir/file with any privileges that should be available, and you are finished. The filesystem did *not* have to go down to every file and write that ACL/permission there.
I remember we had a big hierarchical tree, with every department having their working dir, and within that could define another department having access to some subsdirs if wanted. Like this, everything was secure, and every needed access was quickly possible.
Really, if someone would use that approach for a Linux filesystem, the world would be easier and better. Maybe the btrfs devs read this, then they should look at Netware 3, which already had this neat ACL solution.
(Log in to post comments)
Access Control: take them from Novell Netware Posted Nov 18, 2010 9:01 UTC (Thu) by Fowl (subscriber, #65667) [Link]
Did I miss the explanation of why Windows ACLs are so horrendous?
A list of users/groups and their permissions to this object (and optionally its' children) seems pretty straight forward to me.
Access Control: take them from Novell Netware Posted Nov 18, 2010 9:41 UTC (Thu) by zmi (guest, #4829) [Link]
> Did I miss the explanation of why Windows ACLs are so horrendous?
Maybe you've never had a big file system. Take this example:
Company with 900 employees, 40TB storage in about 40 departments, with a total of 100 million files.
And then someone needs to set a new permission for a top-level dir. Both Unix and Windows ask to write those permissions to all files below that dir. If there are 10 million entries, the session will be blocked for a pretty long time.
Novells Netware didn't have that: Set a new permission, done within the second. I don't know how they stored permissions, but it never depended on the amount of data below that dir.
Also, in Unix and Windows there's a mix of permissions from a share and permissions to a file. In Netware you assigned a right, at that's it. Much easier to review.
Access Control: take them from Novell Netware Posted Nov 18, 2010 10:14 UTC (Thu) by Fowl (subscriber, #65667) [Link]
> If there are 10 million entries, the session will be blocked for a pretty long time.
Ah, I get you. It's the implementation that's the problem, not the concept.
> Both Unix and Windows ask to write those permissions to all files below that dir.
I'm fairly certain Explorer (the Windows shell) uses the most naive method possible for applying permissions.
> Also, in Unix and Windows there's a mix of permissions from a share and permissions to a file. In Netware you assigned a right, at that's it. Much easier to review.
For as long as I can remember giving full access to shares to "Everyone", and then using filesystem permisions has been the recommended practise. It is useful occasionally for enforcing "no remote access" policies, etc.
Access Control: take them from Novell Netware Posted Nov 18, 2010 10:42 UTC (Thu) by zmi (guest, #4829) [Link]
> For as long as I can remember giving full access to shares to "Everyone", and then using filesystem permisions has been the recommended practise.
And it brings the feature "you see the share, but clicking on it tells you you can't access it". Again it's the implementation that's wrong: If I have no right on it anyway, don't display it. Seems to be a lazyness of programmers to have chosen this way.
Access Control: take them from Novell Netware Posted Nov 18, 2010 13:55 UTC (Thu) by mpr22 (subscriber, #60784) [Link] And it brings the feature "you see the share, but clicking on it tells you you can't access it". Again it's the implementation that's wrong: If I have no right on it anyway, don't display it. Seems to be a lazyness of programmers to have chosen this way. Counterpoint:
Access Control: take them from Novell Netware Posted Nov 18, 2010 14:04 UTC (Thu) by dskoll (subscriber, #1630) [Link] Counterpoint: /bin/ls lists the names of directories not owned by the user it's running as whose access control mode is 0700 (user rwx, all others forbidden). Which is perfectly correct behavior according to the way UNIX permissions are defined. The ability to list names in a directory is controlled only by the r bit of the directory itself.
Access Control: take them from Novell Netware Posted Nov 18, 2010 14:16 UTC (Thu) by zmi (guest, #4829) [Link]
ls is a technical unix command, not a user tool (which "clicki-clicki" mouse user knows ls?). ls must show everything, and it follows the kiss principle (keep it small and simple).
Using a graphical dir browser like Dolphin could hide such unreadable contents, that would be nice, as normally users don't need to see that. Should be a config option.
Browsing a server over the network is about 20 years younger "command", solving completely different needs, and it would help security a bit if shares not accessible are not seen by a user. But by the time Microsoft reinvented networking, they did not have the slightest clue about security (and I'd say that only started with Win7, where a user can work as user not admin). Maybe we'll see that improvement once someone at Microsoft gets the idea. Or maybe the Samba team can implement a setting to hide this, and later MS adopts it as it's clever.
Access Control: take them from Novell Netware Posted Nov 21, 2010 0:27 UTC (Sun) by Fowl (subscriber, #65667) [Link]
That issue seems completely unrelated.
Access Control: take them from Novell Netware Posted Nov 18, 2010 17:57 UTC (Thu) by davecb (subscriber, #1574) [Link]
Also from Multics: it is relatively parsimonious, and has the concept of "initial acls", so it really only needs to store acls that are different from the iacl (or from the base acl of the tree).
--dave
Access Control: take them from Novell Netware Posted Nov 18, 2010 20:38 UTC (Thu) by jra (subscriber, #55261) [Link]
> Ah, I get you. It's the implementation that's the problem, not the concept.
No, with Windows ACLs it's the concept.
Look at this:
http://www.pcguide.com/ref/hdd/file/ntfs/secRes-c.html
as an example. Explain that to a user. Don't forget to include why the sort order of DENY's ACE's depends on where in the file hierarchy they came from.
Good luck ! :-)
Jeremy.
Access Control: take them from Novell Netware Posted Nov 21, 2010 0:31 UTC (Sun) by Fowl (subscriber, #65667) [Link]
You recurse up the tree, until you find an applicable entry, with deny taking precedence over allows.
How is that complicated?
Access Control: take them from Novell Netware Posted Nov 18, 2010 9:05 UTC (Thu) by Fowl (subscriber, #65667) [Link]
(Oops, wrong reply button.)
---
Could you explain the Netware model a bit more? It just sounds like ACLs to me.
Access Control: take them from Novell Netware Posted Nov 18, 2010 10:38 UTC (Thu) by zmi (guest, #4829) [Link]
Yes, but not stored within the filesystem, I believe. It never took more than a millisecond to assign a right, no matter how much data was below this dir.
Also, the way you assigned rights was simple: take an object (user, group, department, etc.), assign it to a dir with rights, and specify if it's for subdirs as well or only this dir.
And when you didn't have a right on a dir, you didn't even see it. I dislike the Windows approach of seeing a share, and upon click you get the info "no permission". That's just stupid.
Access Control: take them from Novell Netware Posted Nov 18, 2010 11:09 UTC (Thu) by dgm (subscriber, #49227) [Link]
That would be a nice addition to file managers like Nautilus or Dolphin. Not even showing whatever you cannot open would remove much clutter.
Access Control: take them from Novell Netware Posted Nov 18, 2010 18:43 UTC (Thu) by jeremiah (subscriber, #1221) [Link]
So permissions were only on the directory? and there were no file specific ACL?
Access Control: take them from Novell Netware Posted Nov 18, 2010 22:06 UTC (Thu) by zmi (guest, #4829) [Link]
You could make file ACLs also. But if you specified a dir ACL, it was taken for each file in that dir automatically. That makes sense, as most things are done on a per-dir base anyway, right? At least, if you have a system supporting it that way, you automatically use that approach to order things in directories, as it makes life - and administration! - much easier.
Access Control: take them from Novell Netware Posted Nov 18, 2010 19:05 UTC (Thu) by jeremiah (subscriber, #1221) [Link]
One ACL approach I tried to take once, but the product got dropped before I could see the problems was the following:
you had a file/object, and a list of permissions/security attributes for each object. Object could be a group of objects, but group depth was not a concern. Mutiple applications (controlled by us) could access the permissions, and make decisions based on what they found. If there was a permission that they didn't understand, access was not allowed. This was a situation where we could trust the apps, and not the people. We also took the approach that permissions were subtractive. Everything started as readable/writable and access could only be removed. The nice thing about this was that it was extendable.
This isn't relevant to Novell ACL's just trying to get people's thoughts.
Access Control: take them from Novell Netware Posted Nov 18, 2010 22:09 UTC (Thu) by zmi (guest, #4829) [Link]
From a security point of view, I don't like it. A system should deny everything, and only allow what I explicitly allow. The "default everybody everything yes" way you describe is so Windows, and it's for this reason most viruses are for this system today.
Access Control: take them from Novell Netware Posted Nov 18, 2010 23:41 UTC (Thu) by jeremiah (subscriber, #1221) [Link]
but it seems much harder to administer the other way around. Once something is marked as inaccessible, that's it. You get to stop looking. Where as it seems like when something is marked as visible you have to establish some sort of hierarchy in case a parent thinks it shouldn't be visible. Which would be indicated by nothing being set. Or you run into a situation like unix where you have permissions going either direction and you have to again determine which overrides which. I guess that would be a fail safe as opposed to a fail open though, which I prefer. But SELinux is a clear demonstration of how complicated things can get if you do it in a complete fashion. Starting with the idea that everything is hidden from everything first, and then transitions are made between them. Yet the bail when it comes to initrc, and almost mark everything as visible first.
Access Control: take them from Novell Netware Posted Nov 19, 2010 13:19 UTC (Fri) by jeremiah (subscriber, #1221) [Link]
I feel the urge to clarify my initrc comment. Although it's been a while since I dealt with it, here's what I remember, and some context. I run a payment gateway, so we decided to use SELinux to enforce a true division of roles. We made root a second class citizen to the role a user belonged to. The most difficult part of doing this was that root could transition through rpm_t into initrc_t into any other role on the system. The idea, I think, being that root should be able to install packages, and packages, if they were related to a service, should be able to restart themselves. This had the unwanted effect of giving root the ability to transition to just about anything. Trying to remove the 20 bazillion independent transition paths took a hard 2 weeks. This was with the reference policy, and not a vendor supplied policy, which is much more strict than the strict policy. What it really boiled down to, is what it always boils down to in the end. That delicate balance between usability, and security. In the end it was doable, but it wasn't easy.
I think SELinux is amazingly complete. It allowed us to implement a solution that always requires 2 users, from a group of 3. You throw LUKS, encrypted drives, and removable media into the mix, and you have as close to a bullet proof scenario as possible. On the other hand, I don't want to have to write code that the average admin can't administer without spending a month dealing with a sharp learning curve.
Like a lot of us here I'm a developer, and a system administrator. When I have my development hat on I try to think of the user, and what they have to put up with, while balancing it with security requirements etc. As an administrator, I know I'm willing to tolerate more than most users. The difficult part for me, is defining my target audience, and understanding their abilities and tolerance, and shooting for that. And sometimes the perfect solution, has to be hobbled security wise, or the product won't sell. The only way I've found to begin addressing that is though intelligent defaults, and meaningful dialogs/user interaction.
I am intrigued by the Netware ACL's though, since you seem to have found a happy place when dealing with them as opposed to other permission systems. Thanks for the input.
Access Control: take them from Novell Netware Posted Nov 21, 2010 0:35 UTC (Sun) by Fowl (subscriber, #65667) [Link]
The reason that most viruses are for Windows is the user, plain and simply the huge number of "users". </OT>
If you don't find a specific ACE allowing you access, you don't have access.
|
|||||||||||||