Core Policy versus selinux ebuilds

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Core Policy versus selinux ebuilds

Robert Sharp

Is there a difference between policies that appear to be in core but also have their own ebuilds? For example: selinux-ddclient versus policy/modules/contrib/dnsmasq.* and selinux-ddclient versus policy/modules/contrib/ddclient. I need to change both but when I tried to change dnsmasq it started complaining bitterly about binding to random ports, which is what dnsmasq does.

Just to be absolutely clear, I expect that there is a versioning difference because I have pulled the latest from the git repository but I am using stable ebuilds, but I don't expect that this is the difference?

Thanks in advance,

Robert Sharp

Reply | Threaded
Open this post in threaded view
|

Re: Core Policy versus selinux ebuilds

Jason Zaman-2
On Thu, Apr 13, 2017 at 12:02:24PM +0100, Robert Sharp wrote:
> Is there a difference between policies that appear to be in core but
> also have their own ebuilds? For example: selinux-ddclient versus
> policy/modules/contrib/dnsmasq.* and selinux-ddclient versus
> policy/modules/contrib/ddclient. I need to change both but when I tried
> to change dnsmasq it started complaining bitterly about binding to
> random ports, which is what dnsmasq does.

Not sure i follow exactly what you're asking but lemme give a quick
overview and see if it helps.

- sec-policy/selinux-base
This is the first package installed and everything else depends on it.
It installs all the .if interface files that every other module uses to
build. and also the base configs and stuff for /etc/selinux/ etc.
It also *builds* but does not load base.pp into
/usr/share/selinux/{strict,mcs,targeted}/base.pp
as for what base actually is, its everything that is =base in
policy/modules.conf in the repo

hardened-refpolicy $ grep "= base" policy/modules.conf
corecommands = base
corenetwork = base
devices = base
domain = base
files = base
filesystem = base
kernel = base
mcs = base
mls = base
selinux = base
terminal = base
ubac = base

- sec-policy/selinux-base-policy
this builds the other "core" policies. there isnt really a definition
for what is core but its pretty much things that depend on each other
too much and are always needed but arnt required to be in base.

if you look in the -base-policy ebuild, you see the line:
MODS="application authlogin bootloader clock consoletype cron dmesg fstools getty hostname hotplug init iptables libraries locallogin logging lvm miscfiles modutils mount mta netutils nscd portage raid rsync selinuxutil setrans ssh staff storage su sysadm sysnetwork tmpfiles udev userdomain usermanage unprivuser xdg"
(and also systemd module behind a USE-flag)

the selinux-base-policy ebuild will build all those modules and then at
the end it basically does semodule -i base.pp ${MODS} to load everything
from -base and -base-policy

- sec-policy/selinux-foo
these packages build and load just the module that is in the MODS= line
in the ebuild. its almost always the same as the name as the package but
thats not a requirement or anything.

just because these things are not sec-policy/selinux-base{,-policy}
doesnt mean they all come from the /contrib/ dir inside the repo, there
are several things that are outside cthats not a requirement or
anything. eg: selinux-xserver's files are from services/xserver.{te,if,fc}


> Just to be absolutely clear, I expect that there is a versioning
> difference because I have pulled the latest from the git repository but
> I am using stable ebuilds, but I don't expect that this is the difference?

the versions should be exactly the same for all the sec-policy/selinux-*
packages yeah.

So if you end up updating stuff in the .if files then you'll have to
rebuild selinux-base so your system gets the new interfaces then you
gotta rebuild just the modules you were messing around with.
or you can do emerge @selinux-rebuild and it'll do all of them if you're
lazy.

Hope this makes some of the magic a little clearer,
-- Jason

Reply | Threaded
Open this post in threaded view
|

Re: Core Policy versus selinux ebuilds

Robert Sharp
On 16/04/17 14:31, Jason Zaman wrote:
On Thu, Apr 13, 2017 at 12:02:24PM +0100, Robert Sharp wrote:
Is there a difference between policies that appear to be in core but
also have their own ebuilds? For example: selinux-ddclient versus
policy/modules/contrib/dnsmasq.* and selinux-ddclient versus
policy/modules/contrib/ddclient. I need to change both but when I tried
to change dnsmasq it started complaining bitterly about binding to
random ports, which is what dnsmasq does.
Not sure i follow exactly what you're asking but lemme give a quick
overview and see if it helps.


just because these things are not sec-policy/selinux-base{,-policy}
doesnt mean they all come from the /contrib/ dir inside the repo, there
are several things that are outside cthats not a requirement or
anything. eg: selinux-xserver's files are from services/xserver.{te,if,fc}


Hope this makes some of the magic a little clearer,
-- Jason

Thanks for your explanation. I think I understand. The git repository contains all of the files and the ebuilds pull in different modules? So if I want to change dnsmasq (so that it can talk to unbound on 553) I can just copy the .te/.if/.fc files from the git repository and change them (I have already defined the port in a cil file)?

I just tested this by making the dnsmasq module locally and comparing it to the /usr/share/selinux/strict one and it is the same. So now I can be confident that any changes I make will be the sole source of any problems that might follow!

Fingers crossed and many thanks again for explaining that.

Robert