Extended attribute interfaces

[Andreas Gruenbacher]

On Thu, 21 Sep 2000, Casey Schaufler wrote:

> Andreas Gruenbacher wrote:
> 
> > > What I had in mind was whether privilege allowed violation of the normal
> > > restricted system EAs.
> > 
> > Like setting an invalid ACL? For Posix.1e the rules are well defined who
> > is allowed to change which information when; these rules should not be
> > allowed to be bypassed at all.
> 
> Consider a backup system which uses its own system attribute
> which contains the time of last backup, $tolb. There
> isn't a CAP_TOLB_OVERRIDE. What capability should the backup
> system have? CAP_EXT_ATTR would make sense, but how do you
> prevent the backup system from setting ACLs? (I'm intentionally
> ignoring the fact that you'd want that facility sometimes, BTW)

In my design there simply is no way to set a system attribute that is not
known by the kernel at all, not for anybody. So the only choices the
backup system would have is to either implement a minimal handler for such
an attribute (including all policy issues) or use a user attribute (which
would then be subject to the same restrictions as the file contents, like
in Irix).

System attributes are trusted by the kernel. No user should be allowed to
mess with them in an uncontrolled way.

Allowing new system attributes to be set from user space would lead to the
following problem: A privileged user sets some new system attribute, then
the system gets upgraded and now uses the same attribute internally.

The values the user has set before at best are recognized as invalid. At
worst we have a security hole. (There should be no crashes as the kernel
would always have to assume data on disk could bet corrupted).

What's the mechanism Irix uses exactly? I seem to remember that root can
set root attributes, and other users can set user attributes, but in a
Posix.1e system such a distinction seems wrong to me.


Thanks,
Andreas.


BTW,
    do you have any particular opinion on Marius's ideas? I guess we could
really benefit from input from somebody with a profound unix and security
background  :-)


------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/


To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message