(In reply to comment #6)
> The mechanism for the escalation vector for all of
> setuid/setgid has CVE (and ancient fix resurrected)
> capabilities has CVS (and current fix)
> ACL's "wrong"
> XATTR's SE Linux uses these
> is identical:
>
> Robert uses RPM to install a file on a path attaching metadata to inode.
> Malicious Mark (or Sysadmin Susie) creates a hardlink to the file.
> Robert removes the package and RPM removes the file it created.
At this point, Mark has a hard link to a file that was previously RPM-managed. You haven't described the actual escalation.
> Either _ALL_ or _NONE_ of the metadata cleanup issues that are left attached to
> Mark's
> hardlink that (possibly) can be used as escalation vectors need to be addressed
> by RPM.
POSIX ACLs do not constitute an escalation vector that would allow a user to run the executable with privileges he/she could not otherwise obtain.
(In reply to comment #6)
> The mechanism for the escalation vector for all of
> setuid/setgid has CVE (and ancient fix resurrected)
> capabilities has CVS (and current fix)
> ACL's "wrong"
> XATTR's SE Linux uses these
> is identical:
>
> Robert uses RPM to install a file on a path attaching metadata to inode.
> Malicious Mark (or Sysadmin Susie) creates a hardlink to the file.
> Robert removes the package and RPM removes the file it created.
At this point, Mark has a hard link to a file that was previously RPM-managed. You haven't described the actual escalation.
> Either _ALL_ or _NONE_ of the metadata cleanup issues that are left attached to
> Mark's
> hardlink that (possibly) can be used as escalation vectors need to be addressed
> by RPM.
POSIX ACLs do not constitute an escalation vector that would allow a user to run the executable with privileges he/she could not otherwise obtain.