Is arbitrary access to rpm_t by sysadm_r a security problem?

[Paul Nasrat]

On Wed, Mar 31, 2004 at 06:47:24PM +1000, Russell Coker wrote:
> On Wed, 31 Mar 2004 17:42, Aleksey Nogin <aleksey at nogin.org> wrote:
> > I would imagine sysadm_r can do a lot anyway, but just in case it is a
> > problem, here it is:
> >
> > % id
> > uid=500(aleksey) gid=500(aleksey) groups=500(aleksey)
> > context=aleksey:sysadm_r:sysadm_t
> > % rpm -q rpm --pipe id
> > uid=500(aleksey) gid=500(aleksey) groups=500(aleksey)
> > context=aleksey:sysadm_r:rpm_t
> >
> > Basically, the --pipe option to rpm seems to be giving sysadm_r full
> > access to sysadm_r:rpm_t
 
> Another thing that will need to be done is to have multiple contexts for 
> running rpm for different package signatures.  

Or even signatures determining if scripts/triggers allowed.

Is the current plan to make the trust/role mapping configurable, where would
this be done - within rpmdb or outside.  

I'm curious as to how other implementations work - is this implemented for
Debian at all and how.  

> This will probably require 
> having the current rpm functionality split into two executables.  This means 
> that one can be used for parsing the command line, checking the signature, 
> and running the --pipe operation.  The other could do the real work.

How does this tie in with other uses of rpmlib - eg rpm-python or the C
bindings.  Most people won't be calling rpm directly.

Paul