From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id uAFGUKpj006256 for ; Tue, 15 Nov 2016 11:30:20 -0500 Received: by mail-pf0-f194.google.com with SMTP id 144so8254767pfv.0 for ; Tue, 15 Nov 2016 08:30:19 -0800 (PST) Date: Wed, 16 Nov 2016 00:30:15 +0800 From: Jason Zaman To: Stephen Smalley Cc: SELinux Subject: Re: [RFC] Split up policycoreutils Message-ID: <20161115163015.GA21982@meriadoc.perfinion.com> References: <4633f93f-9a5e-65e8-12d6-f11160be316f@tycho.nsa.gov> <20161114204113.GA9733@meriadoc.perfinion.com> <10c2795c-b4b4-fbe7-6edd-7c24423f6e0a@tycho.nsa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: On Tue, Nov 15, 2016 at 10:01:12AM -0500, Stephen Smalley wrote: > On 11/15/2016 09:47 AM, Stephen Smalley wrote: > > On 11/14/2016 03:41 PM, Jason Zaman wrote: > >> These look pretty good to me. I have written most of the ebuilds for > >> gentoo for these new packages but have not committed to the tree yet. > >> > >> There are a couple issues: > >> 1) What is the license for each of the tarballs? there is no license or > >> COPYING file in the dirs. > > > > Fixed; I copied the policycoreutils/COPYING file into each of the new > > ones since they were all moved from policycoreutils. > > > >> > >> 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused > >> about sepolicy vs sepolgen. there are like 4 separate dirs with those > >> names and the sepolicy Makefile makes a symlink for sepolgen. And then > >> there is the gui and the non-gui part of them. python/sepolicy/* should > >> hopefully die soon as things fully move over to setools4. should gui/ be > >> called system-config-selinux? also is it a redhatism or does it also > >> apply to other distros? > > > > I also find this confusing; hopefully Dan (cc'd) can help clarify > > matters since he wrote most of this code. I do know that the old > > sepolgen package (now python/sepolgen) was just a python module used as > > the backend for audit2allow and intended to become a more general policy > > analysis and generation backend, but never evolved that way, whereas > > gui/sepolgen was the old name for Dan's policy generation script/tool > > that is now just an alias for sepolicy generate. gui could be called > > system-config-selinux, but then it can also be invoked as sepolicy gui. > > It certainly started life as a Red Hat tool, but I'm not sure if anyone > > else is using it. Refactoring all of it, including > > semanage/seobject.py, may make sense. Okay this is roughly what I understood too so thats good. As things get cleaned up more over time hopefully more gets ported to setools4 and then we can start dropping the legacy parts. especially since the ones before setools4 dont completely support policy format 30. > > > >> 3) The deps of each of the bits is somewhat complicated to figure out. > >> semodule-utils looks like it only needs libsepol and libselinux and the > >> others look like they need most of the others? The makefile just builds > >> them in order but i'd like to specify more accurate deps in the gentoo > >> packages (especially external deps for each package) so they get > >> (re)built as required as things update. > > > > I was also trying to make it easy to omit the optional components > > (OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not > > required for operation. I would omit at least dbus, gui, mcstrans, > > restorecond, and sandbox by default from a base install. python is > > likely needed for general purpose distros but could be omitted from > > embedded systems. Actually, I don't see why semodule-utils components > > are linking with libselinux; they do not include selinux.h or make any > > calls to libselinux AFAICS, so I think that only truly depends on libsepol. > > Fixed this too on the branch - removed the -lselinux from semodule-utils > Makefiles. Aha! thanks, I was just looking at the output of ldd and didnt investigate too far. > > > >> Also which of these are required to build refpolicy? the docs on that > >> may need updating later too. > > > > I would only expect libsepol, checkpolicy, and semodule-utils to be > > needed to build refpolicy, while libsemanage and policycoreutils would > > also be needed to install/load refpolicy. > > > >> 4) mcstrans fails to build on my laptop, i'll send patches later. I > >> might have stricter warnings on or something. > > > > Ok, I already had to fix a number of such warnings for it when I > > re-enabled building it by default on that branch (it was disabled > > before), so not surprised - just send the patches our way. > > > >> 5) in python/sepolicy/Makefile: > >> override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils" > >> should that be something instead of policycoreutils now? > > > > Probably can be removed entirely. > > > >> 6) we have a policycoreutils-extra thats been floating around as part of > >> policycoreutils in gentoo. Mainly has rlpkg and selocal. After this > >> split is as good a time as any to cleanup and upstream them. > > > > Ok, in that case we might want to think about what else if anything > > might go there. > > > >> 7) I just noticed when looking through different Makefiles that some > >> variables default to different things. I'll send patches for this too > >> later once its merged in. Its nothing huge just better to be the same. > >> > >>> Note that the release script will add the selinux- prefix for dbus, gui, > >>> python, and sandbox when generating the source tarballs so that they > >>> have unique names suitable for source packages. > >> > >> This makes sense but I wonder if the name prefix is going to be annoying > >> when we end up needing to backport a patch on a release since the paths > >> would be different. But then again we've always had to edit them since > >> they are one level down so I dont think I mind this minor extra bit too. > > > > Open to suggestions; I could add the prefix in the source tree itself; > > it just seemed ugly/unnecessary. Or we could split up the repository > > into multiple ones / submodules, but I'm not keen on that. lets just keep it as-is, its hardly a big deal and there isnt anything all that much better. It all looks good to me currently. Cant think of anything else that should be done before merging it in. -- Jason