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