restorecon vs. setfiles

[Gary Peck]

For some reason restorecon and setfiles have different notions of what
context certain files should be. For example:

# ls -Z /usr/lib/libz.*
-rwxr-xr-x+ root     root     system_u:object_r:lib_t /usr/lib/libz.a
lrwxrwxrwx+ root     root     system_u:object_r:lib_t /usr/lib/libz.so ->
libz.so.1.2.1.1
lrwxrwxrwx  root     root     system_u:object_r:lib_t /usr/lib/libz.so.1 ->
libz.so.1.2.1.1
-rwxr-xr-x  root     root     system_u:object_r:shlib_t /usr/lib/libz.so.1.2.1.1

# restorecon -v /usr/lib/libz.*
restorecon set context /usr/lib/libz.so->system_u:object_r:shlib_t
restorecon set context /usr/lib/libz.so.1->system_u:object_r:shlib_t

# setfiles -v /etc/security/selinux/file_contexts /usr/lib/libz.*
setfiles:  read 1450 specifications
setfiles:  labeling files under /usr/lib/libz.a
setfiles:  hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1
setfiles:  labeling files under /usr/lib/libz.so
setfiles:  relabeling /usr/lib/libz.so from system_u:object_r:shlib_t to
system_u:object_r:lib_t
setfiles:  hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1
setfiles:  labeling files under /usr/lib/libz.so.1
setfiles:  relabeling /usr/lib/libz.so.1 from system_u:object_r:shlib_t to
system_u:object_r:lib_t
setfiles:  hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1
setfiles:  labeling files under /usr/lib/libz.so.1.2.1.1
setfiles:  hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1
setfiles:  Done.

So, restorecon thinks that *.so files should be shlib_t, whereas
setfiles thinks they should be lib_t. Which one is right and why do they
disagree? I thought that they both get their context info from the same
place.

This is with policy-1.11.3-5 and policycoreutils-1.11-4.

gary

[Aleksey Nogin]

On 18.05.2004 19:22, Gary Peck wrote:

>  For some reason restorecon and setfiles have different notions of
> what
>  context certain files should be. For example: 
[...]
>  So, restorecon thinks that *.so files should be shlib_t, whereas
>  setfiles thinks they should be lib_t. Which one is right and why do they
>  disagree? I thought that they both get their context info from the same
>  place. 
It seems the two disagree on symlinks. May be restorecon forgets to 
check whether its argument is a symlink?

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: [phone]

[Daniel J Walsh]

Aleksey Nogin wrote:

>  On 18.05.2004 19:22, Gary Peck wrote:
>
> > For some reason restorecon and setfiles have different notions of what
> > context certain files should be. For example:
>
>  [...]
>
> > So, restorecon thinks that *.so files should be shlib_t, whereas
> > setfiles thinks they should be lib_t. Which one is right and why do they
> > disagree? I thought that they both get their context info from the same
> > place.
>
>
>  It seems the two disagree on symlinks. May be restorecon forgets to 
>  check whether its argument is a symlink?
>  
Looks like a bug in matchpathcon (Which is used buy restorecon).  It is 
returning the wrong security context.  I will send this to stephen.  
Basically looks like it is ignoring file type.

Dan

[Stephen Smalley]

On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote:
>  Looks like a bug in matchpathcon (Which is used buy restorecon).  It
> is 
>  returning the wrong security context.  I will send this to stephen.  
>  Basically looks like it is ignoring file type. 
matchpathcon takes a pathname and optional file mode as input parameters
for matching against the file contexts configuration.  It doesn't
attempt to stat the file itself to obtain the mode because it is
sometimes used by programs that are creating new files (e.g. udev) and
want to know the context for the file they are about to create, so it
requires the caller to provide the mode.  restorecon currently passes 0
as the mode, so no mode matching is performed.

So this is a bug in restorecon; it needs to be changed to stat the file
and provide the mode.

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Daniel J Walsh]

Stephen Smalley wrote:

> On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote:
>   
>
> >Looks like a bug in matchpathcon (Which is used buy restorecon).  It is 
> >returning the wrong security context.  I will send this to stephen.  
> >Basically looks like it is ignoring file type.
> >    
> >
>
> matchpathcon takes a pathname and optional file mode as input parameters
> for matching against the file contexts configuration.  It doesn't
> attempt to stat the file itself to obtain the mode because it is
> sometimes used by programs that are creating new files (e.g. udev) and
> want to know the context for the file they are about to create, so it
> requires the caller to provide the mode.  restorecon currently passes 0
> as the mode, so no mode matching is performed.
>
> So this is a bug in restorecon; it needs to be changed to stat the file
> and provide the mode.
>
>   
>  
policycoreutils-1.12-2 has two fixes for restorecon, it handles the 
symbolic link problem and ignores <<none>>.

Dan

[Gary Peck]

>  >matchpathcon takes a pathname and optional file mode as input
>  >parameters for matching against the file contexts configuration.  It
>  >doesn't attempt to stat the file itself to obtain the mode because it
>  >is sometimes used by programs that are creating new files (e.g. udev)
>  >and want to know the context for the file they are about to create,
>  >so it requires the caller to provide the mode.  restorecon currently
>  >passes 0 as the mode, so no mode matching is performed.
>  >
>  >So this is a bug in restorecon; it needs to be changed to stat the
>  >file and provide the mode. 
Looks like a similar bug might be present in rpm, or at least the end
result is similar. Whenever I install new RPM's from Rawhide, *.so*
files get installed with object_r:lib_t context. If I run
"/sbin/fixfiles restore" right afterward, they get relabeled back to
object_r:shlib_t.  Either rpm has an old policy version on the Rawhide
build machines, or it's not labeling files correctly.

Also, the dev package in Rawhide comes with all files labeled as
object_r:device_t. After running fixfiles, some of those get relabeled
to the correct object_r:fixed_disk_device_t, object_r:tty_device_t,
object_r:sound_device_t, etc. dev should have the correct contexts to
begin with. Various files in /usr/sbin also don't have the correct
contexts as shipped in the RPM's.

This is all with selinux-policy-targeted-1.13.8-1,
policycoreutils-1.13.3-2, and rpm-4.3.2-0.4.

Gary

[Daniel J Walsh]

Stephen Smalley wrote:

> On Fri, 2004-06-25 at 12:34, Gary Peck wrote:
>   
>
> >Looks like a similar bug might be present in rpm, or at least the end
> >result is similar. Whenever I install new RPM's from Rawhide, *.so*
> >files get installed with object_r:lib_t context. If I run
> >"/sbin/fixfiles restore" right afterward, they get relabeled back to
> >object_r:shlib_t.  Either rpm has an old policy version on the Rawhide
> >build machines, or it's not labeling files correctly.
> >
> >Also, the dev package in Rawhide comes with all files labeled as
> >object_r:device_t. After running fixfiles, some of those get relabeled
> >to the correct object_r:fixed_disk_device_t, object_r:tty_device_t,
> >object_r:sound_device_t, etc. dev should have the correct contexts to
> >begin with. Various files in /usr/sbin also don't have the correct
> >contexts as shipped in the RPM's.
> >
> >This is all with selinux-policy-targeted-1.13.8-1,
> >policycoreutils-1.13.3-2, and rpm-4.3.2-0.4.
> >    
> >
>
> I don't believe that rpm is computing file contexts at package build
> time anymore, since there are multiple policies (strict and targeted)
> now.  It should instead compute the file contexts when unpacking the
> package based on your local file_contexts configuration, whose path is
> obtained from /usr/lib/rpm/macros using /etc/selinux/config to determine
> the active policy.  It seems to be working for me.
>
>   
>  
Any chance the so files are getting created in a post install script?  
rpm should be working the same as restorecon and setfiles.

Dan

[Stephen Smalley]

On Fri, 2004-06-25 at 12:34, Gary Peck wrote:
>  Looks like a similar bug might be present in rpm, or at least the
> end
>  result is similar. Whenever I install new RPM's from Rawhide, *.so*
>  files get installed with object_r:lib_t context. If I run
>  "/sbin/fixfiles restore" right afterward, they get relabeled back to
>  object_r:shlib_t.  Either rpm has an old policy version on the Rawhide
>  build machines, or it's not labeling files correctly.
>  
>  Also, the dev package in Rawhide comes with all files labeled as
>  object_r:device_t. After running fixfiles, some of those get relabeled
>  to the correct object_r:fixed_disk_device_t, object_r:tty_device_t,
>  object_r:sound_device_t, etc. dev should have the correct contexts to
>  begin with. Various files in /usr/sbin also don't have the correct
>  contexts as shipped in the RPM's.
>  
>  This is all with selinux-policy-targeted-1.13.8-1,
>  policycoreutils-1.13.3-2, and rpm-4.3.2-0.4. 
I don't believe that rpm is computing file contexts at package build
time anymore, since there are multiple policies (strict and targeted)
now.  It should instead compute the file contexts when unpacking the
package based on your local file_contexts configuration, whose path is
obtained from /usr/lib/rpm/macros using /etc/selinux/config to determine
the active policy.  It seems to be working for me.

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Stephen Smalley]

On Fri, 2004-06-25 at 12:56, Daniel J Walsh wrote:
>  Any chance the so files are getting created in a post install script?
>  
>  rpm should be working the same as restorecon and setfiles. 
The .so symlink might be created by %post, but that is ok, as it just
gets the type of the parent directory anyway.  Only the actual shared
object should have shlib_t, and that should be installed by rpm.

rpm source code appears to be passing the mode as part of the lookup, so
I don't think that is the issue.

rpm -Uvh --force libselinux*.rpm keeps the correct security context on
/lib/libselinux.so.1 for me, both on a strict policy machine and a
targeted policy machine.  rpm is 4.3.2-0.4; I haven't updated to -1 yet.

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Gary Peck]

On Fri, Jun 25, 2004 at 01:44:15PM -0400, Stephen Smalley wrote:
>  rpm source code appears to be passing the mode as part of the
> lookup,
>  so I don't think that is the issue.
>  
>  rpm -Uvh --force libselinux*.rpm keeps the correct security context on
>  /lib/libselinux.so.1 for me, both on a strict policy machine and a
>  targeted policy machine.  rpm is 4.3.2-0.4; I haven't updated to -1
>  yet. 
Could this be an issue with apt? I'm actually using apt-get to install
these packages. When I tried using "rpm -Uvh ..." directly, it seemed to
set the contexts correctly as you say. However, when I did it with
apt-get again, I saw the same problem. Here's some files from the
mozilla package with their correct contexts:

system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaccessibility.so
system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaddrbook.so
system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libappcomps.so
system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libautoconfig.so

Then I run "apt-get install mozilla", which upgrades mozilla from
1.7-0.3.1 to 1.7-0.3.2. Afterwards, these same files (but from the new
version of mozilla) have the following contexts:

root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaccessibility.so
root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaddrbook.so
root:object_r:lib_t /usr/lib/mozilla-1.7/components/libappcomps.so
root:object_r:lib_t /usr/lib/mozilla-1.7/components/libautoconfig.so

I assumed that apt's behaviour should be the same since it's just using
rpm underneath, but maybe there's extra rpm API calls that need to be
made by apt when it's running on a SELinux system?

This is with apt-0.5.15cnc6-0.fdr.11.2, rpm-4.3.2-0.4.

gary

apt and selinux (was: Re: restorecon vs. setfiles)

[Gary Peck]

On Sat, Jun 26, 2004 at 05:12:34PM -0700, Gary Peck wrote:
>  Could this be an issue with apt? I'm actually using apt-get to
> install
>  these packages. When I tried using "rpm -Uvh ..." directly, it seemed to
>  set the contexts correctly as you say. However, when I did it with
>  apt-get again, I saw the same problem. Here's some files from the
>  mozilla package with their correct contexts:
>  
>  system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaccessibility.so
>  system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaddrbook.so
>  system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libappcomps.so
>  system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
>  
>  Then I run "apt-get install mozilla", which upgrades mozilla from
>  1.7-0.3.1 to 1.7-0.3.2. Afterwards, these same files (but from the new
>  version of mozilla) have the following contexts:
>  
>  root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaccessibility.so
>  root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaddrbook.so
>  root:object_r:lib_t /usr/lib/mozilla-1.7/components/libappcomps.so
>  root:object_r:lib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
>  
>  I assumed that apt's behaviour should be the same since it's just using
>  rpm underneath, but maybe there's extra rpm API calls that need to be
>  made by apt when it's running on a SELinux system?
>  
>  This is with apt-0.5.15cnc6-0.fdr.11.2, rpm-4.3.2-0.4. 
Ok, I'm pretty sure it's an apt problem now. I tried installing the same
package twice, once with apt using the rpm API directly (apt-get install
...), and once with apt calling the rpm binary externally (apt-get -o
RPM::PM="external" install ...). When using the API, I see the same
problem as above. When calling the rpm binary, the contexts get set
correctly.

I've CC'ed the apt-rpm list as it's probably a more appropriate place
for this discussion. Anyone there care to comment?

gary

[apt-rpm] apt and selinux (was: Re: restorecon vs. setfiles)

[Panu Matilainen]

On Sat, 26 Jun 2004, Gary Peck wrote:

>  On Sat, Jun 26, 2004 at 05:12:34PM -0700, Gary Peck wrote:
>  > Could this be an issue with apt? I'm actually using apt-get to install
>  > these packages. When I tried using "rpm -Uvh ..." directly, it seemed to
>  > set the contexts correctly as you say. However, when I did it with
>  > apt-get again, I saw the same problem. Here's some files from the
>  > mozilla package with their correct contexts:
>  > 
>  > system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaccessibility.so
>  > system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaddrbook.so
>  > system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libappcomps.so
>  > system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
>  > 
>  > Then I run "apt-get install mozilla", which upgrades mozilla from
>  > 1.7-0.3.1 to 1.7-0.3.2. Afterwards, these same files (but from the new
>  > version of mozilla) have the following contexts:
>  > 
>  > root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaccessibility.so
>  > root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaddrbook.so
>  > root:object_r:lib_t /usr/lib/mozilla-1.7/components/libappcomps.so
>  > root:object_r:lib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
>  > 
>  > I assumed that apt's behaviour should be the same since it's just using
>  > rpm underneath, but maybe there's extra rpm API calls that need to be
>  > made by apt when it's running on a SELinux system?
>  > 
>  > This is with apt-0.5.15cnc6-0.fdr.11.2, rpm-4.3.2-0.4.
>  
>  Ok, I'm pretty sure it's an apt problem now. I tried installing the same
>  package twice, once with apt using the rpm API directly (apt-get install
>  ...), and once with apt calling the rpm binary externally (apt-get -o
>  RPM::PM="external" install ...). When using the API, I see the same
>  problem as above. When calling the rpm binary, the contexts get set
>  correctly.
>  
>  I've CC'ed the apt-rpm list as it's probably a more appropriate place
>  for this discussion. Anyone there care to comment? 
I wouldn't call it an apt-problem, you just need to put it into same 
context as rpm. This should already be the case on Fedora Core 2, dunno 
about upstream selinux policy packages - this is from stock FC2 
/etc/security/selinux/src/policy/file_contexts/program/rpm.fc:
/usr/bin/apt-get        --      system_u:object_r:rpm_exec_t
/usr/bin/apt-shell      --      system_u:object_r:rpm_exec_t
/usr/bin/synaptic   --          system_u:object_r:rpm_exec_t

	- Panu -

[apt-rpm] apt and selinux (was: Re: restorecon vs. setfiles)

[Stephen Smalley]

On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote:
>  I wouldn't call it an apt-problem, you just need to put it into
> same 
>  context as rpm. This should already be the case on Fedora Core 2, dunno 
>  about upstream selinux policy packages - this is from stock FC2 
>  /etc/security/selinux/src/policy/file_contexts/program/rpm.fc:
>  /usr/bin/apt-get        --      system_u:object_r:rpm_exec_t
>  /usr/bin/apt-shell      --      system_u:object_r:rpm_exec_t
>  /usr/bin/synaptic   --          system_u:object_r:rpm_exec_t 
It isn't just a policy issue; rpm had to be modified for SELinux to set
file security contexts when creating files.  Those changes are in the
upstream rpm, and yum seems to work as expected when updating.
  
-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[apt-rpm] apt and selinux (was: Re: restorecon vs. setfiles)

[Gary Peck]

On Mon, Jun 28, 2004 at 02:53:52PM -0400, Stephen Smalley wrote:
>  On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote:
>  > I wouldn't call it an apt-problem, you just need to put it into same 
>  > context as rpm. This should already be the case on Fedora Core 2, dunno 
>  > about upstream selinux policy packages - this is from stock FC2 
>  > /etc/security/selinux/src/policy/file_contexts/program/rpm.fc:
>  > /usr/bin/apt-get        --      system_u:object_r:rpm_exec_t
>  > /usr/bin/apt-shell      --      system_u:object_r:rpm_exec_t
>  > /usr/bin/synaptic   --          system_u:object_r:rpm_exec_t 
The context is not the problem. I'm running the targeted policy from
FCdev, which makes both /bin/rpm and /usr/bin/apt*
system_u:object_r:bin_t. rpm works fine, however, whereas apt-get does
not.

>  It isn't just a policy issue; rpm had to be modified for SELinux
> to
>  set file security contexts when creating files.  Those changes are in
>  the upstream rpm, and yum seems to work as expected when updating. 
I believe apt needs similar modifications. The attached patch to apt
fixes the problem for me. I'm not too familiar with rpm, apt, or selinux
internals, so this patch might need some work.  I just took the code
from rpm's lib/rpminstall.c/rpmInstall() function which seemed to be
missing in apt's apt-pkg/rpm/rpmpm.cc/pkgRPMLibPM::Process() function.

Before the patch, running "apt-get install --reinstall zlib" produced
this result:
    # rpm -q --fscontext zlib
    /usr/lib/libz.so.1      root:object_r:lib_t
    /usr/lib/libz.so.1.2.1.1        root:object_r:lib_t
    /usr/share/doc/zlib-1.2.1.1     system_u:object_r:usr_t
    /usr/share/doc/zlib-1.2.1.1/README      system_u:object_r:usr_t

After the patch, running "apt-get install --reinstall zlib" produced
this result:
    # rpm -q --fscontext zlib
    /usr/lib/libz.so.1      system_u:object_r:lib_t
    /usr/lib/libz.so.1.2.1.1        system_u:object_r:shlib_t
    /usr/share/doc/zlib-1.2.1.1     system_u:object_r:usr_t
    /usr/share/doc/zlib-1.2.1.1/README      system_u:object_r:usr_t

The correct result, according to rpm, is the second one:
    # rpm -q --recontext zlib
    /usr/lib/libz.so.1      system_u:object_r:lib_t
    /usr/lib/libz.so.1.2.1.1        system_u:object_r:shlib_t
    /usr/share/doc/zlib-1.2.1.1     system_u:object_r:usr_t
    /usr/share/doc/zlib-1.2.1.1/README      system_u:object_r:usr_t

gary

[apt-rpm] apt and selinux (was: Re: restorecon vs. setfiles)

[Panu Matilainen]

On Mon, 28 Jun 2004, Gary Peck wrote:

>  On Mon, Jun 28, 2004 at 02:53:52PM -0400, Stephen Smalley wrote:
>  > On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote:
>  > > I wouldn't call it an apt-problem, you just need to put it into same 
>  > > context as rpm. This should already be the case on Fedora Core 2, dunno 
>  > > about upstream selinux policy packages - this is from stock FC2 
>  > > /etc/security/selinux/src/policy/file_contexts/program/rpm.fc:
>  > > /usr/bin/apt-get        --      system_u:object_r:rpm_exec_t
>  > > /usr/bin/apt-shell      --      system_u:object_r:rpm_exec_t
>  > > /usr/bin/synaptic   --          system_u:object_r:rpm_exec_t
>  
>  The context is not the problem. I'm running the targeted policy from
>  FCdev, which makes both /bin/rpm and /usr/bin/apt*
>  system_u:object_r:bin_t. rpm works fine, however, whereas apt-get does
>  not. 
Ok, the policy has changed in the development tree since FC2 release,
apt-rpm *was* working ok with the above context settings the last I
looked.

>  
>  > It isn't just a policy issue; rpm had to be modified for SELinux to
>  > set file security contexts when creating files.  Those changes are in
>  > the upstream rpm, and yum seems to work as expected when updating.
>  
>  I believe apt needs similar modifications. The attached patch to apt
>  fixes the problem for me. I'm not too familiar with rpm, apt, or selinux
>  internals, so this patch might need some work.  I just took the code
>  from rpm's lib/rpminstall.c/rpmInstall() function which seemed to be
>  missing in apt's apt-pkg/rpm/rpmpm.cc/pkgRPMLibPM::Process() function. 
Much of the code in pkgRPMLibPM is lifted more-or-less directly from 
rpmInstall(), no problem with that :) I'll have a closer look at this one 
of these days but basically the patch seems fine to me if that's what rpm 
itself does.

	- Panu -

[apt-rpm] apt and selinux (was: Re: restorecon vs. setfiles)

[Panu Matilainen]

On Tue, 2004-06-29 at 01:32, Gary Peck wrote:
>  On Mon, Jun 28, 2004 at 02:53:52PM -0400, Stephen Smalley wrote:
>  > On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote:
>  > > I wouldn't call it an apt-problem, you just need to put it into same 
>  > > context as rpm. This should already be the case on Fedora Core 2, dunno 
>  > > about upstream selinux policy packages - this is from stock FC2 
>  > > /etc/security/selinux/src/policy/file_contexts/program/rpm.fc:
>  > > /usr/bin/apt-get        --      system_u:object_r:rpm_exec_t
>  > > /usr/bin/apt-shell      --      system_u:object_r:rpm_exec_t
>  > > /usr/bin/synaptic   --          system_u:object_r:rpm_exec_t
>  
>  The context is not the problem. I'm running the targeted policy from
>  FCdev, which makes both /bin/rpm and /usr/bin/apt*
>  system_u:object_r:bin_t. rpm works fine, however, whereas apt-get does
>  not.
>  
>  > It isn't just a policy issue; rpm had to be modified for SELinux to
>  > set file security contexts when creating files.  Those changes are in
>  > the upstream rpm, and yum seems to work as expected when updating.
>  
>  I believe apt needs similar modifications. The attached patch to apt
>  fixes the problem for me. I'm not too familiar with rpm, apt, or selinux
>  internals, so this patch might need some work.  I just took the code
>  from rpm's lib/rpminstall.c/rpmInstall() function which seemed to be
>  missing in apt's apt-pkg/rpm/rpmpm.cc/pkgRPMLibPM::Process() function. 
Had a closer look and the patch indeed seems correct: applied, thanks!

	- Panu -