[gentoo-dev] We need *you* for a USE="selinux" dependency

December 04th, 2011 - 03:40 pm ET by Sven Vermeulen | Report spam
Hi guys 'n gals

obligatory tl;dr:
Please check your package below this list and see if it (the package) has
a proper DEPEND and RDEPEND on the listed sec-policy/selinux-<module> package(s)

Within the Gentoo Hardened project, we are working on getting the SELinux
support into shape. Recent evolutions are the stabilization of latest upstream
userspace utilities and policies as well as documentation improvements and even
some "human resource improvements" (read: fresh blood in our ranks).

Within SELinux, specific modules are used (called SELinux modules, because we
are not that creative in our naming) that contain the SELinux policy (what is
allowed) as well as labeling information for files (which we call file context
information). This labeling is very important in order for the policies to work
well - wrong labels will lead to applications running with wrong permissions
(which usually means "Application No Workie").

In Gentoo, unlike some other distributions, we try to keep the number of
loaded/installed modules to a minimum so that policy rebuilds as well as the
system overhead is limited. This results in a "base" policy (provided by
selinux-base-policy) and modules (provided by sec-policy/selinux-<modulename>). To make
sure that installations of a package pull in the right SELinux module, the
proper dependencies must be defined.

In the list below you will find "package dependency" information. This means
that the given package should have both DEPEND and RDEPEND on the dependency
(which is always of the form sec-policy/selinux-<modulename> since dependencies
on sec-policy/selinux-base-policy are always satisfied the moment a user has SELinux
enabled on his Gentoo system).

The dependency should be USE="selinux"-triggered (the selinux USE flag is masked
for non-SELinux profiles and mandatory on SELinux systems), like so:
IUSE="selinux"
DEPEND="selinux? ( sec-policy/selinux-<modulename> )"
RDEPEND="selinux? ( sec-policy/selinux-<modulename> )"

The dependency must be on both levels, because the SELinux module must be
installed before the package is installed (and in theory, RDEPEND could
trigger an installation afterwards): during the installation phase, Portage
labels the files on the system (which would get wrong labels if the module
isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package
support requirements.

Since there are quite a few packages that would need updates, I thought about
first mailing gentoo-dev for feedback and perhaps a first chunk of work done. I
also wouldn't mind creating bugreports for each of them, but that would still be
best done after having mailed gentoo-dev ;-)

Wkr,
Sven Vermeulen

[1] I am aware that Portage currently installs RDEPEND before the package
itself, but that might change in the future and other package managers might
exhibit different behavior.

games-board/aisleriot sec-policy/selinux-games
sys-apps/apmd sec-policy/selinux-apm
net-dns/bind sec-policy/selinux-bind
net-wireless/bluez sec-policy/selinux-bluetooth
app-i18n/canna sec-policy/selinux-canna
app-cdr/cdrkit sec-policy/selinux-cdrecord
app-cdr/cdrtools sec-policy/selinux-cdrecord
app-antivirus/clamav sec-policy/selinux-clamav
net-im/climm sec-policy/selinux-games
mail-mta/courier sec-policy/selinux-courier
net-print/cups sec-policy/selinux-lpd
dev-vcs/cvs sec-policy/selinux-cvs
sys-process/daemontools sec-policy/selinux-daemontools
sys-process/daemontools-encore sec-policy/selinux-daemontools
mail-filter/dcc sec-policy/selinux-dcc
app-admin/denyhosts sec-policy/selinux-denyhosts
sys-devel/distcc sec-policy/selinux-distcc
net-dns/djbdns sec-policy/selinux-djbdns
app-arch/dpkg sec-policy/selinux-dpkg
app-cdr/dvd+rw-tools sec-policy/selinux-cdrecord
www-client/epiphany sec-policy/selinux-mozilla
x11-misc/expocity sec-policy/selinux-wm
net-analyzer/fail2ban sec-policy/selinux-fail2ban
app-arch/fastjar sec-policy/selinux-java
net-mail/fetchmail sec-policy/selinux-fetchmail
www-client/firefox-bin sec-policy/selinux-mozilla
dev-java/gcj-jdk sec-policy/selinux-java
dev-vcs/gitolite sec-policy/selinux-gitosis
dev-vcs/gitolite-gentoo sec-policy/selinux-gitosis
dev-vcs/gitosis sec-policy/selinux-gitosis
dev-vcs/gitosis-gentoo sec-policy/selinux-gitosis
virtual/gnat sec-policy/selinux-ada
gnome-base/gnome-applets sec-policy/selinux-cpufreqselector
gnome-extra/gnome-games sec-policy/selinux-games
gnome-base/gnome-shell sec-policy/selinux-wm
app-crypt/gnupg sec-policy/selinux-gpg
www-servers/gorg sec-policy/selinux-gorg
gpe-base/gpe-dm sec-policy/selinux-xserver
net-print/hplip sec-policy/selinux-cups
x11-apps/iceauth sec-policy/selinux-xserver
net-misc/icecast sec-policy/selinux-icecast
net-nntp/inn sec-policy/selinux-inn
kde-base/katomic sec-policy/selinux-games
kde-base/kbattleship sec-policy/selinux-games
sys-apps/kbd sec-policy/selinux-loadkeys
kde-base/kblackbox sec-policy/selinux-games
kde-base/kbounce sec-policy/selinux-games
kde-base/kgoldrunner sec-policy/selinux-games
kde-base/kgpg sec-policy/selinux-gpg
net-wireless/kismet sec-policy/selinux-kismet
kde-base/kjumpingcube sec-policy/selinux-games
kde-base/klickety sec-policy/selinux-games
kde-base/klines sec-policy/selinux-games
kde-base/kmahjongg sec-policy/selinux-games
kde-base/kmines sec-policy/selinux-games
kde-base/kolf sec-policy/selinux-games
kde-base/konquest sec-policy/selinux-games
kde-base/kpat sec-policy/selinux-games
kde-base/kreversi sec-policy/selinux-games
kde-base/kshisen sec-policy/selinux-games
kde-base/kspaceduel sec-policy/selinux-games
kde-base/ktron sec-policy/selinux-games
kde-base/ktuberling sec-policy/selinux-games
app-emulation/libvirt sec-policy/selinux-xen
www-client/links sec-policy/selinux-links
kde-base/lskat sec-policy/selinux-games
dev-db/mariadb sec-policy/selinux-mysql
net-misc/memcached sec-policy/selinux-memcached
x11-wm/metacity sec-policy/selinux-wm
sys-apps/mlocate sec-policy/selinux-slocate
www-servers/mongrel sec-policy/selinux-apache
media-sound/mpd sec-policy/selinux-mpd
sys-cluster/mpich2 sec-policy/selinux-mpd
media-video/mplayer sec-policy/selinux-mplayer
media-video/mplayer2 sec-policy/selinux-mplayer
net-analyzer/mrtg sec-policy/selinux-mrtg
mail-client/mutt sec-policy/selinux-mutt
dev-db/mysql sec-policy/selinux-mysql
media-libs/nas sec-policy/selinux-soundserver
net-misc/netcf sec-policy/selinux-ncftool
net-ftp/netkit-ftpd sec-policy/selinux-publicfile
mail-mta/netqmail sec-policy/selinux-qmail
net-analyzer/ntop sec-policy/selinux-ntop
net-misc/nxserver-freeedition sec-policy/selinux-nx
net-misc/nxserver-freenx sec-policy/selinux-nx
x11-wm/openbox sec-policy/selinux-wm
net-misc/openconnect sec-policy/selinux-vpn
net-nntp/pan sec-policy/selinux-pan
sys-boot/plymouth sec-policy/selinux-plymouthd
app-admin/prelude-lml sec-policy/selinux-prelude
app-admin/prelude-manager sec-policy/selinux-prelude
mail-filter/procmail sec-policy/selinux-procmail
net-ftp/proftpd sec-policy/selinux-ftp
www-servers/publicfile sec-policy/selinux-publicfile
media-sound/pulseaudio sec-policy/selinux-pulseaudio
app-admin/puppet sec-policy/selinux-puppet
dev-python/pyzor sec-policy/selinux-pyzor
app-emulation/qemu sec-policy/selinux-qemu
app-emulation/qemu-kvm sec-policy/selinux-qemu
www-apps/roundup sec-policy/selinux-roundup
app-arch/rpm sec-policy/selinux-rpm
app-shells/rssh sec-policy/selinux-rssh
net-fs/samba sec-policy/selinux-samba
app-misc/screen sec-policy/selinux-screen
net-mail/serialmail sec-policy/selinux-daemontools
net-im/skype sec-policy/selinux-skype
net-nntp/slrn sec-policy/selinux-slrnpull
mail-filter/spamassassin sec-policy/selinux-spamassassin
net-misc/stunnel sec-policy/selinux-stunnel
net-nntp/suck sec-policy/selinux-inn
net-misc/taylor-uucp sec-policy/selinux-uucp
media-sound/timidity++ sec-policy/selinux-timidity
net-irc/tirc sec-policy/selinux-irc
net-misc/tor sec-policy/selinux-tor
media-tv/tvtime sec-policy/selinux-tvtime
x11-wm/twm sec-policy/selinux-wm
sys-apps/ucspi-tcp sec-policy/selinux-ucspitcp
sys-apps/usermode-utilities sec-policy/selinux-uml
www-servers/varnish sec-policy/selinux-varnishd
net-misc/vde sec-policy/selinux-vde
media-video/vlc sec-policy/selinux-mplayer
app-emulation/vmware-workstation sec-policy/selinux-vmware
net-analyzer/vnstat sec-policy/selinux-vnstatd
app-admin/webalizer sec-policy/selinux-webalizer
app-emulation/wine sec-policy/selinux-wine
net-analyzer/wireshark sec-policy/selinux-wireshark
net-wireless/wpa_supplicant sec-policy/selinux-networkmanager
x11-apps/xauth sec-policy/selinux-xserver
media-video/xine-ui sec-policy/selinux-mplayer
x11-base/xorg-server sec-policy/selinux-xprint
x11-base/xorg-server sec-policy/selinux-xprint
x11-misc/xscreensaver sec-policy/selinux-xscreensaver
sys-apps/yum sec-policy/selinux-rpm
email Follow the discussionReplies 12 repliesReplies Make a reply

Similar topics

Replies

#1 Petteri Räty
December 04th, 2011 - 04:00 pm ET | Report spam
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

On 04.12.2011 22:35, Sven Vermeulen wrote:
Hi guys 'n gals

obligatory tl;dr:
Please check your package below this list and see if it (the package) has
a proper DEPEND and RDEPEND on the listed sec-policy/selinux-<module> package(s)




The list would be easier to read if it was sorted. Also it should be
quite easy to check automatically that the atoms in place.

Regards,
Petteri




Replies Reply to this message
#2 Fabio Erculiani
December 04th, 2011 - 05:20 pm ET | Report spam
On Sun, Dec 4, 2011 at 9:35 PM, Sven Vermeulen wrote:
[...]
The dependency must be on both levels, because the SELinux module must be
installed before the package is installed (and in theory, RDEPEND could
trigger an installation afterwards): during the installation phase, Portage
labels the files on the system (which would get wrong labels if the module
isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package
support requirements.


Wkr,
       Sven Vermeulen

[1] I am aware that Portage currently installs RDEPEND before the package
   itself, but that might change in the future and other package managers might
   exhibit different behavior.




I haven't really understood what you mean with RDEPENDs being scheduled "after".
RDEPEND must be always scheduled before the pkg requiring it, changing
this behaviour would have disruptive effects on all the PMS out there
(OTOH I think I haven't gotten the point actually?). I guess portage
may schedule it in arbitrary order if the RDEPEND dep itself is
satisfied already (this would mean that you explicitly pulled it in),
and this is the only case I can think of.
If you need to schedule a dep install at some point, you should rather
use PDEPEND, but if the same is required earlier in the schedule,
well, you're flooked.

Fabio Erculiani
http://lxnay.com
Replies Reply to this message
#3 Mike Frysinger
December 04th, 2011 - 06:00 pm ET | Report spam

On Sunday 04 December 2011 15:35:50 Sven Vermeulen wrote:
Since there are quite a few packages that would need updates, I thought
about first mailing gentoo-dev for feedback and perhaps a first chunk of
work done. I also wouldn't mind creating bugreports for each of them, but
that would still be best done after having mailed gentoo-dev ;-)



i generally don't want to see bug reports that say "please add IUSE=selinux to
XXX package and add 'selinux? ( sec-policy/selinux-XXX )' to *DEPEND". if
selinux wants policies pulled in by packages based on USE=selinux, and that's
the only change needed, then feel free to commit the change yourself for any
toolchain / base-system / vapier package. probably easiest to skip the
revbump and just commit to existing packages since selinux has been deadish
for quite sometime :P.

games-board/aisleriot sec-policy/selinux-games



i don't see why this game is singled out. if you have a selinux policy for
all games, then it sounds like we should add this logic to games.eclass.

net-im/climm sec-policy/selinux-games



you sure about that one ? this isn't a game (unless you count all forms of IM
a "game" :p).

and yes, this list really really should have been sent through `sort`
-mike



Replies Reply to this message
#4 Brian Harring
December 04th, 2011 - 10:10 pm ET | Report spam
On Sun, Dec 04, 2011 at 11:10:17PM +0100, Fabio Erculiani wrote:
On Sun, Dec 4, 2011 at 9:35 PM, Sven Vermeulen wrote:
> [...]
> The dependency must be on both levels, because the SELinux module must be
> installed before the package is installed (and in theory, RDEPEND could
> trigger an installation afterwards): during the installation phase, Portage
> labels the files on the system (which would get wrong labels if the module
> isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package
> support requirements.
>
>
> Wkr,
> ?? ?? ?? ??Sven Vermeulen
>
> [1] I am aware that Portage currently installs RDEPEND before the package
> ?? ??itself, but that might change in the future and other package managers might
> ?? ??exhibit different behavior.
>

I haven't really understood what you mean with RDEPENDs being scheduled "after".
RDEPEND must be always scheduled before the pkg requiring it,



While it appears that way, it's not actually true; RDEPEND is what the
pkg requires to be able to be usable, not what is required to merge
it.

Key thing there is the 'run' part; the manager can merge a pkg that
isn't yet usable (unsatisfied rdeps), as long as nothing in the graph
currently requires the pkg to be working at that state in the build
plan.

Assuming pkg x DEPENDs on a, and RDEPENDS on b for the context of this
discussion, it's perfectly valid for the manager to sequentially build
and merge (a, x, b). At the point 'b' is merged, 'x' is considered
satisfied/usable.

This is the long term rules; the reason it's not obvious is because
it's rare for the graph to be flexed in such a fashion that a,x,b is
forced rather than a,b,x. Cycles, blockers, odd deps, etc, can
force it however.


If you need to schedule a dep install at some point, you should rather
use PDEPEND, but if the same is required earlier in the schedule,
well, you're flooked.



In the context of this discussion (apply selinux policies), PDEPEND
isn't valid; PDEPEND should be used strictly for for deps that are
RDEPEND required, but the pkg can function (degraded) without; this
being done for cycle breaking reasons. Well aware people don't always
abide by those terms, but that's the actual rules.

Selinux wise, the policy needs to be available for applying at merge
time, so PDEPEND doesn't fly.
~harring
Replies Reply to this message
#5 Rich Freeman
December 04th, 2011 - 10:20 pm ET | Report spam
On Sun, Dec 4, 2011 at 5:10 PM, Fabio Erculiani wrote:
I haven't really understood what you mean with RDEPENDs being scheduled "after".
RDEPEND must be always scheduled before the pkg requiring it, changing
this behaviour would have disruptive effects on all the PMS out there



There is only one PMS out there, unless you're counting versions (they
are cumulative so the latest approved one should be the one you use -
correct me if I'm wrong there). PMS != package manager.

In this particular case the approved PMS says "In the pkg phases, at
least one of the following conditions must be met: any command
provided by a packaged listed in DEPEND is available; any command
provided by a packaged listed in RDEPEND is available." Perhaps
somebody with a more twisted sense of logic than I can make some sense
out of that - to me it suggests that an ebuild can safely assume that
either the packages listed in DEPEND are available, or the packages
listed in RDEPEND are available, but not necessarily both (though you
could count on RDEPEND if you have DEPEND=RDEPEND set or are using an
EAPI that has this behavior).

I suspect that the PMS team has already noticed that since the current
non-approved PMS is a bit more clear. It says (in a table) that any
of the pkg phases can assume that the RDEPENDs are there "(unless the
particular dependency results in a circular dependency, in which case
it may be installed later)." I guess that means that pkg phases can't
assume that RDEPENDs are there after all. Additionally pkg_config can
assume that RDEPEND and PDEPEND are present (with no caveats). None
of the pkg phases can assume that anything in DEPEND is present
(obviously unless it is also in RDEPEND).

My sense is that none of the PMS versions really say quite what we
want the behavior to be - as to be truly compliant ebuilds would have
to require nothing outside of the base system in the pkg phases (other
than pkg_config) - then again, maybe we can live with that. It
doesn't seem to add much value to say that RDEPEND /might/ be
available - the necessary conditional logic to take advantage of a
command that might or might not be present seems like a QA nightmare.
We should probably specify that ebuilds either can safely count on
RDEPEND, or not, in each of the phases.

(Disclaimer - I claim no special knowledge of the mechanics of your
favorite package manager - I'm simply reading the specs.)

Rich
Replies Reply to this message
Help Create a new topicNext page Replies Make a reply
Search Make your own search