In tracking some issues in a separate bug (that will shortly depend on this one), I track down a file labeling problem down to this block of code: ifdef(`distro_gentoo', ` /usr/.*-.*-linux-gnu/gcc-bin/.*(/.*)? gen_context(system_u:object_r:bin_t,s0) /usr/.*-.*-linux-gnu/binutils-bin(/.*)? gen_context(system_u:object_r:bin_t,s0) ') I look at the definitions and think "that looks right, why isn't it working?" because binutils-bin is *not* being labeled correctly. So I peel off the ifdef() because I have no idea why, and I find that restorecon properly labels things. And just to hammer the point home, uncomment the ifdef so it actually controls code flow again: testbed ~ # restorecon /usr/x86_64-pc-linux-gnu/binutils-bin/ -Rv restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24 context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/gprof context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/ld.gold context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/ranlib context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/dwp context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strip context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/ld.bfd context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/readelf context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/c++filt context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/size context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/as context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/elfedit context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/nm context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/objdump context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/objcopy context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/addr2line context system_u:object_r:bin_t->system_u:object_r:usr_t restorecon reset /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/ar context system_u:object_r:bin_t->system_u:object_r:usr_t Wondering what on earth is going on, I track down where the distro variable is set and I find that build.conf in the current reference policy isn't set to anything. At all. What this means is that *every ifdef statement* has been a no-op for....probably a long time now. This is impacting 72 distinct policy modules, and has an effect I can find. Including some solutions to bug reports I've recently filed, which is amusing. Now, I concede that it is possible that this is a massive user error on my part. However my reading of the development guide hasn't ran across this yet, and when I do a sanity check and pull the base policy via portage and check build.conf the exact same issue shows up. Because my filesystem has not been labeled correctly in certain hard to spot areas due to this from the beginning make me believe this is legitimate. The fix for this is pretty simple: DISTRO=gentoo in build.conf Then rebuild. Am I missing something, or did something this big seriously not get noticed? Reproducible: Always
(In reply to Eric Gisse from comment #0) > ifdef(`distro_gentoo', ` Hi, What version of the SELinux userspace are you on? are you on the 2.4_rc ones or 2.3? and if you are on 2.4, have you done the migration and were there any issues during it? My machine is on 2.3 still and I have no such issue: # matchpathcon /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/as /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/as system_u:object_r:bin_t Hopefully it is not another problem with the pp2cil translation.
The machine I'm working on is about 3 weeks old, so I do not have any legacy issues around which means file labeling is also fresh. My policycoreutils version is 2.4_rc5 which is what is current in ~amd64, however the issue I'm looking at here is an artifact of the base policy and thus the reference policy in git. The remark about the pp2cil transition interests me though, as I periodically see errors like this when building pp's: # semodule -i sysnetwork.pp sysnetwork: Warning: 'else' blocks in optional statements are unsupported in CIL. Dropping from output. I'm not writing if/else logic, for the record. So in terms of a migration, I have not done one because this is a fresh build.
so the refpolicy is still written the old way. but the new userland takes input as CIL now so the .pp files are converted from .pp into .cil and the policy is then built and loaded. Can you take a look in the cached .cil files (should be in /var/lib/selinux somewhere i think) and see if the fcontext has been translated into cil correctly? (the syntax of cil is completely different its no longer but its close enough you should recognize things still.
Alright. from /var/lib/selinux/strict/active/modules/400/base/cil : (filecon "/usr/.*-.*-linux-gnu/gcc-bin/.*(/.*)?" any (system_u object_r bin_t (systemlow systemlow))) (filecon "/usr/.*-.*-linux-gnu/binutils-bin(/.*)?" any (system_u object_r bin_t (systemlow systemlow))) So let's break this down into pieces. 1) Understand that while I am generally competent / confident with selinux, exact developmental nuances like "a massive policy base rewrite" will elude me. I'm keying off the SELinux development guide, using what's the current hardened project's reference policy in git, and generally trying to not make an ass of myself more than is necessary. I have no idea what the issue with CIL beyond an occasional build complaint from reference policies that I hadn't put time into isolating due to wanting to fix actual issues. 2) The system I built was straight to policycoreutils 2.4 with whatever was ~amd64's current base policy at that time. As such, binutiils-bin was not labeled correctly. Which also means there has been no migration between major selinux components. Fresh build. 3) The build process I am following for my own reference policy work (which is generating a crapload of legitimate issues) uses the same Makefile as what the in-tree base policy is using, which should emphasize piece #2. I built the system THEN I started screwing with the reference policy as a means to an end. Now, I'm going to treat CIL as a black box. Because at this timeslice it is. You say the userland utilities takes the .pp input, then converts it to CIL. Alright. The input is still broken, and I think proven so. Regardless of what's going on with CIL parsing, because the relevant policies *are not making it that far* due to the make issue. Unless I'm missing something important, which is entirely possible. Honestly though, CIL looks better. The language whose name I have already forgotten is awful. But that's neither here or there.
Eric, can you please post the file_contexts file in /etc/selinux/strict/contexts/files/file_contexts?
Created attachment 389296 [details] file_contexts This is not going to be helpful for you. The file_contexts file you are getting is the one where I have the correct labeling fixed. If you want one, built a selinux policy the way portage does out of ~amd64.
Did the CIL filecontext's in comment #4 also come from the fixed policy? Also, I don't have a Gentoo system set up, so I can't easily test to figure out what is going on.
Yeah, they did come from the fixed policy as far as I understand how that tree is being populated.
Ok, then I agree that it probably sounds like Eric is correct, that the problem is that DISTRO is not getting set to "gentoo". Though it's odd that it works for Jason Zaman in comment #1. Eric, would it be possible to post the base.cil and/or the file_contexts file generated from policy before your fix was applied? It's possible that this is a file_context ordering issue, which could have potentially changed between 2.3 and 2.4.
Hi Eric The build.conf file is updated, unconditionally, in the sec-policy/selinux-base package (the src_configure() phase). The files are installed in /usr/share/selinux/*/include (with * depending on the policy stores you want to have on the system - for instance "strict" or "mcs") You can check the build.conf file in that location. If it was indeed missing the "DISTRO ?= gentoo" part in it, we need to figure out how that build.conf file was installed then. You can always try to reproduce by moving build.conf aside and reinstalling selinux-base. BTW, on my system: ~# matchpathcon /usr/x86_64-pc-linux-gnu/binutils-bin/ /usr/x86_64-pc-linux-gnu/binutils-bin system_u:object_r:bin_t:s0
Scratch my last comment. I'm noticing a lot of weird things happening (I probably forgot to rebuild the modules after moving to rc6). Rolling back to rc5 also doesn't seem to fix things - I'm now back on the stable 2.3. I'll get back when I have more info
Right now I'm really confused. I go through and rebuild the base policy again, do a relabel, and nothing changes (read: works right). But then I sit and think "But I was seeing portage transition and binutils labeling issues when I first built the machine, and I definitely meant to get to them later which is why I'm here." I really don't want to build a new selinux box in a vm just for testing / sorting out whether I'm nuts. Its' a pain in the ass. Where's that bug I saw that talked about selinux autobuilds...
I am running the 2.4_rc6-r1 tools now and do not see this happen anymore. Pretty sure it was just a problem with the tools which has now been fixed. If you upgrade to 2.4_rc6-r1, can you verify if this issue still exists for you? (better to nuke the /var/lib/selinux dir before you do the upgrade)
I'm on the 2.3 userspace tree at the moment, so it isn't easy for me to test.
No worries; I'll mark it as WORKSFORME for now and once 2.4 is more stabilized then we can see if it still occurs for you or not.
