Has anyone tried to activate SELINUX in Fedora 25?
pels
[ 1.510532] audit: type=1404 audit(1505894636.317:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
[ 1.601491] audit: type=1403 audit(1505894636.408:3): policy loaded auid=4294967295 ses=4294967295
[ 1.605815] systemd[1]: Successfully loaded SELinux policy in 95.611ms.
[ 1.617897] systemd[1]: Failed to mount tmpfs at /run: Permission denied
[.[0;1;31m!!!!!!.[0m] Failed to mount API filesystems, freezing.
[ 1.621206] systemd[1]: Freezing execution.
I had it enabled in fedora 24 but after upgrading failed
I create a new template (f25 and f25-minimal) with same effect.
I have tried to reset SELinux to its initial state:
yum remove selinux-policy
rm -rf /etc/selinux
yum install selinux-policy-targeted
fixfiles -f -F relabel
reboot
Any ideas?
Thank you very much
Best Regards
cooloutac
When googling this error seems people have same issue when running docker. And you have to set seccomp to unconfined.
pels
Thank you cooloutac
-Is this a vm
It happens in Templates and VMs.
-Is this a vm, if so do we really care if systemd is running in it?
The problem is when i enable SELINUX VMs/templates doesn't "boot" or fail to start.
If I disable SELINUX, the templates/VMs start whithout problems and systemd is activated.
-You sure thats selinux?
Yes i'm pretty sure, it's exactly the same config that i had in fedora24.
In dom0
qvm-prefs -s fedora-25 kernelopts "nopat security=selinux selinux=1"
and in VMs/Templats
/etc/selinux/config
SELINUX=enforcing
SELINUXTYPE=targeted
Default selinux config
-what does sestatus say?
I can't execute anything in template/VMs
in dom0:
qvm-run fedora-25 --nogui -pass-io -u root "sestatus"
Error(fedora-25): Domain 'fedora-25':qreexec not connected
-When googling this error seems people have same issue when running docker. And you have to set seccomp to unconfined
Yes, i've read it, but i don't know how disable seccomp and the consequences...
Could you make me a big favour and try to activate SELINUX?
Thank you very much
Best regards
jkitt
> [ 1.617897] systemd[1]: Failed to mount tmpfs at /run: Permission denied
> [.[0;1;31m!!!!!!.[0m] Failed to mount API filesystems, freezing.
> [ 1.621206] systemd[1]: Freezing execution.
Looks like a tmpfs cannot be mounted at boot. In actual fact: these default policies are never in a "ready to deploy" state. You have to run the policy in permissive mode - throughout the normal boot process, and typical use of the confined binaries. Once you have built a log of fired rules then you have to go back and tweak the policy. There are, shockingly, no good tools to parse selinux audit logs outwith a couple of hard to get tools - distributed in the redhat repos. I think there is a Gentoo overlay that you can reverse engineer, or maybe you can find a working tool. But once you have ironed out all the policy violations,and you can boot without firing anything of concern, then you are ready for enforcing mode.
Here are some good primers on the subject. The first video, in particular, shows how to effectively parse audit logs - with the aforementioned redhat tool:
pels
Thank you jkitt for the videos, i'm going to investigate.
cooloutac
Probably only useful in the template vm. But still not sure how beneficial it would be was my point though. Its probably not compatible with qubes, sounds like it breaks qrexec, maybe not worth the headache man.
cooloutac
If they exploiting xen already I don't think it really matters at that point. But i'm far from an expert.
cooloutac
I'm sorry for spam, but wanted to add an alternative option is use multiple template vms for installing diff untrusted software, of course this requires more resources, but Qubes in general requires more resources and specific capable hardware for best compatibility.
pels
Thank you cooloutac. Probably not a big deal, i'm not going to spent a lot of time, but i'd like to know why works in fedora 24 and not in fedora 25. If I find the solution i'll posted. Probaly i can't find the solution, because my knowledge is limited.
Thank you again.
Steve Coleman
to turn the permission violations into new permit rules. Those permit
rules will allow the system to boot normally once applied to the system
policy. This process may need to be repeated.
I used to use this script back when I was using tcsh on a stock Fedora
system, but it would be trivial to change to bash or just use the
command line:
#!/bin/tcsh
echo
# find the avc entries for the application in the log file
grep "$argv[1]" /var/log/audit/audit.log > "my$argv[1].out"
# pass those entries to audit to allow
cat "my$argv[1].out" | audit2allow -M "my$argv[1]"
# display the generated policy so you can learn what its doing
cat "my$argv[1].te"
echo
# Just output to stdout the command needed to commit the new policy,
# this is for cut and paste command execution
echo semodule -i my$argv[1].pp
echo
Basically you give the script a search string and it grep locates all
avc permission violations containing that application-name/error-message
and creates a policy file to fix those specific problems, and then it
echos the command needed to actually fix it to the console. If you agree
with those permissions displayed you simply copy and paste that command
back into the command line and press enter. Keep the *.te,*.pp files for
any future upgrades should you need to repeat this on another system.
If you were running in permissive mode nothing will fail but the system
will still log those avc violations. Once you have run the *.te file to
update the policy, on the next boot those avc messages should be
resolved, if so, turn on the se enforcement (targeted mode) and try
booting again. Rinse and repeat as necessary until your system boots
properly, then you can focus on the user application side of things.
Targeted mode is best for the user, as it denies any system services
from running that you didn't give permission to run but does not block
the user from getting their work done.
As for Xen itself, there is also the Flask architecture (SELinux equiv)
built into Xen, so that might be interesting to see what it can do with
regards to a determined hacker. I have not seen how to enable that in a
stock qubes system without rebuilding everything.
I personally feel that simply enabling the permissive audit logging
could be quite protective simply by detecting any tampering, but only if
there were a realtime process that could monitor the log to alert the
user to the presence of a hacker/malware tampering with the system. The
adversary has to try things that would normally get logged, and thus
leave fingerprints on your system. Hardware enforced separation is
great, but if you have an intruder then you really do want to know when
to put the shields up and begin to analyze the damage to plan your next
actions. The sooner you know you are not alone the better. How you
recover can be highly dependent on how long you have been subverted by
your adversary, and what the did to get a foothold on your system. AVC
audits may show you exactly how they did it, thus once you recover you
may be able to plug those holes. Without this important information they
will be back, you can count on it.
If you do pursue this challenge please keep me informed of your progress
off line preferably. While I agree with the qubes developers that don't
see it as a big preventive measure, given that users all have sudo, I do
however think that getting a first-warning upon their entry can be key
to keeping the system safe to use. What you do after they have a
foothold is dependent on what you are protecting.
good luck!
Steve Coleman
pels
Thank you very much Steve Coleman.