On 09/26/2017 05:35 AM, pels wrote:
On Sunday, September 24, 2017 at 6:19:15 PM UTC+2, cooloutac wrote:
On Sunday, September 24, 2017 at 12:17:33 PM UTC-4, cooloutac wrote:
On Sunday, September 24, 2017 at 12:16:34 PM UTC-4, cooloutac wrote:
On Thursday, September 21, 2017 at 4:40:42 AM UTC-4, pels wrote:
On Wednesday, September 20, 2017 at 2:54:31 PM UTC+2, cooloutac wrote:
On Wednesday, September 20, 2017 at 4:41:58 AM UTC-4, pels wrote:
I'd like to activate SELINUX(enforcing) in VMs (f25 and f25-minimal), but fails:
[ 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
Is this a vm, if so do we really care if systemd is running in it? You sure thats selinux? what does sestatus say?
When googling this error seems people have same issue when running docker. And
you have to set seccomp to unconfined.
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
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.
Try running SELinux in permissive mode then use the SELinux audit2allow
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
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/75d9dc32-ecb5-30b5-ccc7-84235f5bcec2%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.
