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

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

[Sven Vermeulen]

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

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

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Fabio Erculiani]

On Sun, Dec 4, 2011 at 9:35 PM, Sven Vermeulen <swift@gentoo.org> 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

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

[Brian Harring]

On Sun, Dec 04, 2011 at 11:10:17PM +0100, Fabio Erculiani wrote:
> On Sun, Dec 4, 2011 at 9:35 PM, Sven Vermeulen <swift@gentoo.org> 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

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

[Fabio Erculiani]

On Mon, Dec 5, 2011 at 4:04 AM, Brian Harring <ferringb@gmail.com> wrote:
> [..]
>
> 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.
> [...]

Correct, I didn't want to be so picky on the explanation.

-- 
Fabio Erculiani

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

[Rich Freeman]

On Sun, Dec 4, 2011 at 5:10 PM, Fabio Erculiani <lxnay@gentoo.org> 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

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

[Duncan]

Rich Freeman posted on Sun, 04 Dec 2011 22:10:19 -0500 as excerpted:

> 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.

tl;dr folks can skip.  This is just an explanation for those who might 
need it, tho the usual disclaimers about not being a PM or PMS guru 
apply, so assuming I've got it straight, myself.

You are, I believe, correct as to the pkg phase requirements -- other 
than pkg_config, they actually require nothing other than @system.  The 
second-to-last paragraph has the solution already proposed by the PM/PMS 
folks, but there's some resistance, reasons explained there.

It helps to keep in mind the situation with 100% binpkg installations 
that do no building, along with RDEPEND's cycle-breaking role.  Obviously 
DEPEND can't be counted on there since such systems do no building.  
Equally obviously, RDEPEND must eventually be installed for full runtime 
functionality, but can't be depended on during the pkg phases so as to 
fill the circular dependency requirements.

The distinction between PDEPEND and RDEPEND, then, is that PDEPEND is 
more like a strong recommendation, it should be installed as well, but 
the package doesn't depend on it to actually run so installation can be 
put off more or less indefinitely, while RDEPEND is assumed to be there 
as soon as the package is installed, since at that point it's assumed to 
be runnable and RDEPEND is runtime dependencies.  So RDEPEND can't be 
depended upon during installation (both src and pkg phases, other than 
pkg_config but like PDEPEND, that can be put off indefinitely, from the 
PM's and thus PMS perspective), but IS depended upon IMMEDIATELY AFTER 
installation, as the package is then considered runnable and thus RDEPEND 
must be installed, while PDEPEND installation can be put off effectively 
indefinitely.

In practice, because a package is assumed to be runnable as soon as it is 
fully installed, RDEPEND is NORMALLY installed first and thus there for 
most or all phases, as that's the easiest way to ensure that the package 
is fully runnable after the PM is done with that package, but that's not 
REQUIRED to be the case, and in a circular dependency bind, a PM MAY have 
to wait until after all installation phases are complete, then pause 
before actually certifying it so and install the RDEPEND then.

As a paused install, the PM can then fudge the dependencies of the 
circularly dependent package since the paused install /is/ actually 
installed, all installation phases complete, it's just waiting on that 
circular dependency RDEPEND to take the installation off pause and 
certify it as fully installed.

For build-systems, putting a package in both DEPEND and RDEPEND thus in 
practice assures that it's installed during pkg_preinst and pkg_postinst, 
since the PM isn't likely to install it for building, then uninstall it, 
then ensure that it's installed after installation at runtime again, but 
that doesn't work on 100% binpkg installations either, since they don't 
have to consider DEPEND at all because the package isn't being built.

This corner-case is why Ciaran and others involved with the PMs and PMS 
have recommended adding additional dependency types, among them, one that 
would be required during the post-build install phases (pkg_preinst and 
pkg_postinst).  That recommendation hasn't gone anywhere, however, 
because in most cases the existing deps are "good enough", and at some 
point, there's simply too many *DEPEND types to effectively keep track 
of, such that the additional costs aren't considered worth the trouble of 
the corner-case solution.

I suppose that corner-case might be one reason I occasionally have 
installation failures on big updates such as kde, but with --keep-going, 
portage continues to install other packages, and at some point manually 
retrying the failed installation "just works".  The other reason (other 
than the occasional job token miscount, -j* issue when multiple merges 
are going on, or other apparently random build-system failure) is of 
course incompletely specified deps in the dependency thicket of upstream 
kde's monolithic tarball buildsystem, but I can't fault gentoo/kde for 
missing something there occasionally, particularly when it's not 
reproducible afterward because the ordering has been resolved!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On Sun, 4 Dec 2011 22:10:19 -0500
Rich Freeman <rich0@gentoo.org> wrote:
> 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."

Yeah, that's a screwup that's been discussed at length. It shouldn't be
giving you any guarantees at all for pkg_*, since RDEPEND-RDEPEND
cycles need to be breakable (there are lots of them in the tree).

The fix is likely going to be an IDEPEND or something along those lines
in the next EAPI.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1277 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

El dom, 04-12-2011 a las 17:53 -0500, Mike Frysinger escribió:
> 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.

I fully agree with Mike here, feel free to change it in packages
maintained by me (I have seen bluez ;))

> 
> > 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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On 12/4/11 9:35 PM, Sven Vermeulen wrote:
> 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).

This is excellent progress! Kudos for working on this.

> 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.

Are you sure this is right choice? It seems to me that it'd be better to
focus no making things work, and increasing the complexity of the deps
makes this harder (and increasing the number of packages you maintain
too). Unless you have _abundant_ resources to deal with that, I'd like
to discourage you from handling policies that way.

Furthermore, imagine I'm adding a new package "foo" that is covered by
the SELinux policy. Most developers don't use SELinux (hey, I suspect
most of them don't even use developer profile; bad, bad!). How do I know
whether it's sec-policy/selinux-foo that's not yet added or
sec-policy/selinux-games or something else... If the complete policy is
in one package, this should be obvious, and we don't even need deps for
that.

> 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 ;-)

As said by other devs here, I also think it'd be more effective if you
just do the change yourself. USE="selinux" doesn't affect anything else
so it's safe.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Sven Vermeulen]

On Mon, Dec 05, 2011 at 08:54:13AM +0100, "Paweł Hajdan, Jr." wrote:
> > 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.
> 
> Are you sure this is right choice? It seems to me that it'd be better to
> focus no making things work, and increasing the complexity of the deps
> makes this harder (and increasing the number of packages you maintain
> too). Unless you have _abundant_ resources to deal with that, I'd like
> to discourage you from handling policies that way.

For end users, this is much more enjoyable. If we load up all policies, then
any interaction with the SELinux policies will take some time. Also, all
policies in memory do take up some space. Finally, for development purposes,
this is very much enjoyable as well, since it allows for much faster policy
development (rebuild policies in seconds to minutes rather than dozen of
minutes).

Maintenance is actually pretty easy. The eclass we use provides us with a
very easy interface to add modules, and because it is a module per ebuild,
we can push changes on individual modules without pushing full policy builds
again.

> Furthermore, imagine I'm adding a new package "foo" that is covered by
> the SELinux policy. Most developers don't use SELinux (hey, I suspect
> most of them don't even use developer profile; bad, bad!). How do I know
> whether it's sec-policy/selinux-foo that's not yet added or
> sec-policy/selinux-games or something else... If the complete policy is
> in one package, this should be obvious, and we don't even need deps for
> that.

I know. This is one major hurdle that we need to take on. Using dependencies
is the "easiest" approach, albeit the most resource intensive one
(initially, that is). I don't mind having the dependencies added as we go.
For our end users, we already documented that missing modules are to be
expected and how to resolve it.

> As said by other devs here, I also think it'd be more effective if you
> just do the change yourself. USE="selinux" doesn't affect anything else
> so it's safe.

Ok, no problem. I'll check on IRC regardless, if not just to give a "heads
up" on changes.

Also, my apologies for not sorting the list. Careful readers will notice it
is sorted, but by the package name, not category :/ 

Thanks you all for the feedback!

Wkr,
	Sven Vermeulen

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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On 12/5/11 9:42 PM, Sven Vermeulen wrote:
> For end users, this is much more enjoyable. If we load up all policies, then
> any interaction with the SELinux policies will take some time. Also, all
> policies in memory do take up some space. Finally, for development purposes,
> this is very much enjoyable as well, since it allows for much faster policy
> development (rebuild policies in seconds to minutes rather than dozen of
> minutes).

I wasn't aware that dealing with the policies is so slow.

Just how about providing a meta package pulling all policies just in
case someone wants to do that?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]