On Thu, 26 Oct 2000, Craig Ruff wrote:
> On Thu, Oct 26, 2000 at 11:02:52PM +0200, Andreas Gruenbacher wrote:
> > Sorry, but I think the root namespace is a serious misdesign. The root
> > user shouldn't be treated specially at all. In a system that fully
> > supports capabilities, it's actually possible for root to have no
> > permissions whatsoever. Allowing root to manipulate EAs of files
> > effectively makes root omnipotent again (by manipulating the capabilities
> > of files, etc.)
>
> How do you prevent users from using EA keys that are used for essential
> system services (e.g. HSM support)?
By not giving them access to that part of the EA namespace that they
shouldn't have access to.
> Are you going to require that a default EA for these keys that is
> automatically propagated to all new file/directories be setup by the
> admin before file system use? In this case, it would seem that you
> would need to attach ACLs to these EAs to prevent the user from
> manipulating or deleting them. What happens if the admin needs to
> convert an existing file system to support an HSM?
No, not at all. System security objects like Posix 1003.1e ACLs and
Capabilities (and others, too) have clearly defined semantics. To make the
case for Posix ACLs:
- Everybody who is allowed to search a directory may also read the ACLs of
the files in that directory.
- Only the file owner or a user capable of CAP_FOWNER may change the ACLs
of files.
- In addition, nobody, ever, should be able to set an ACL to an invalid
value, even if they are allowed to set the ACL.
This is exactly the policy the kernel must enforce. Nothing more, nothing
less. Creating additional paths to manipulating ACLs (say, by allowing
ACLs implemented as EAs to be manipulated directly through the EA
interface in an incompatible way) is _very_ evil. It's just as evil if the
user doing the manipulations is the superuser.
On the other hand, even if you had separate ACL syscalls, those syscalls
would need to enforce that policy as well. So my approach is to enforce
the policy in the EA interface directly (I'm using EA handlers in the
kernel for that right now).
That way, the EA interface can be used also for manipulating ACLs, so no
additional interfaces are needed. All EAs can be manipulated through the
same interface, so things stay much simpler. Even backing up / restoring
the EAs of a file isn't difficult through that interface, without opening
any security holes.
Andreas
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
