Is arbitrary access to rpm_t by sysadm_r a security problem?

[Aleksey Nogin]

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

[Russell Coker]

On Wed, 31 Mar 2004 17:42, Aleksey Nogin  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

By design sysadm_r can do everything, including disabling SE Linux.  So being 
able to get rpm_t is no problem.

In future we will provide an option to have a secadm_r role to perform 
security administration and a sysadm_r role that can only be used for basic 
sysadm tasks.  Such a mode of operation will conflict with the --pipe command 
for rpm.  When we implement that we will have to do something about the 
--pipe command, either disable it or have it cause a domain transition back 
to the calling domain.

Another thing that will need to be done is to have multiple contexts for 
running rpm for different package signatures.  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.

These are just some wild ideas.  Hopefully Jeff will be available to give some 
better ones.

[Paul Nasrat]

On Wed, Mar 31, 2004 at 06:47:24PM +1000, Russell Coker wrote:
> On Wed, 31 Mar 2004 17:42, Aleksey Nogin  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

[Aleksey Nogin]

On 31.03.2004 01:37, Paul Nasrat wrote:
> > 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.

I am guessing that the "internal" trusted executable could be called 
from rpmlib and be the one doing all the stuff that requires special 
permissions and this way it would not matter what "front end" 
(rpm/apt/yum/up2date/etc) is used. I have no idea whether the current 
rpmlib API would support something like this, so I could be wrong.