Re: [PATCH] last misc stuff

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/6/19 2:38 AM, Dominick Grift wrote:
Russell Coker <russell@xxxxxxxxxxxx> writes:

On Sunday, 6 January 2019 6:04:14 AM AEDT Chris PeBenito wrote:
Index: refpolicy-2.20180701/policy/modules/admin/apt.fc
===================================================================
--- refpolicy-2.20180701.orig/policy/modules/admin/apt.fc
+++ refpolicy-2.20180701/policy/modules/admin/apt.fc
@@ -1,9 +1,12 @@
/etc/cron\.daily/apt    --
gen_context(system_u:object_r:apt_exec_t,s0)

-ifndef(`distro_redhat',`
+/usr/bin/apt           --
gen_context(system_u:object_r:apt_exec_t,s0) /usr/bin/apt-get        --
    gen_context(system_u:object_r:apt_exec_t,s0) -/usr/bin/apt-shell
--      gen_context(system_u:object_r:apt_exec_t,s0) /usr/bin/aptitude
    --      gen_context(system_u:object_r:apt_exec_t,s0)
+/usr/sbin/update-apt-xapian-index --
gen_context(system_u:object_r:apt_exec_t,s0) +
+ifndef(`distro_redhat',`
+/usr/bin/apt-shell     --
gen_context(system_u:object_r:apt_exec_t,s0) /usr/sbin/synaptic      --
    gen_context(system_u:object_r:apt_exec_t,s0)
/usr/lib/packagekit/packagekitd --
gen_context(system_u:object_r:apt_exec_t,s0) /var/cache/PackageKit(/.*)?
    gen_context(system_u:object_r:apt_var_cache_t,s0)
I modified some of these changes, as it results in file context
conflicts with the RPM module.  More accurately, I removed the fc
entries in RPM that label the apt executables.  I moved the apt-shell
back out of the ifndef block.

I think the synaptic and packagekit fc entries, which are in both apt
and rpm modules, may need to be dropped and move to the distro's
patches.  Either that, or this ifndef needs to turn into ifdef debian
(or something else).

Otherwise merged.

I agree that things should be reconsidered with apt policy.

Do we even need separate apt and rpm policy given that both package managers
have access to write everything and change config files?

AFAIK, apt can probably just be part of the rpm domain. Heck even dpkg
can be. The only thing , i think, that in that case should be taken care of
is to make a typealias rpm_script_t dpkg_script_t because dpkg has
selinux awareness and wants to manually transition to dpkg_script_t to
execute the scriptlets

I'd be open to merge the two modules, if they're similar enough. I'd be nice to compare the two modules more deeply; unfortunately one feature I haven't reimplemented from setools3 was the type relationship analysis, which would be perfect for this.

--
Chris PeBenito



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux