Extended attribute interfaces
Marius Bendiksen
mbendiks at eunet.no
Thu Sep 21 17:38:28 GMT 2000
> 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
In that case, you will need at least three classes of EAs, or a full DACL
featureset for EAs. I'd propose "system.", "trusted." and "user." if the
former.
> 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
This is an unnecessary requirement to impose, and an unreasonable one to
the minds of many developers.
> would then be subject to the same restrictions as the file contents, like
> in Irix).
The problem being that the user can then introduce untrusted data to a
trusted application, as a user can set his/her own attributes.
> System attributes are trusted by the kernel. No user should be allowed to
> mess with them in an uncontrolled way.
Unless the user has the appropriate privileges to do so.
> 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.
This is avoided by having a clearly segmented namespace, in the case of
malicious intent, and by having decently named attributes (with long
names) in the non-malicious case.
> 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).
You would get a potential security problem with sticking system data in
user attributes too. And I'd say all trusted programs' per-object data can
be considered user attributes.
> 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.
My suggestion would be three segments, or full DACL.
> 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 :-)
This we would, yes.
The only feedback I've received so far has been from you and Robert. This
is an important topic, and I wouldn't want to see anything go wrong due to
the lack of feedbeck.
Marius
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message
More information about the posix1e
mailing list