On Thursday, September 28, 2017 at 5:59:09 PM UTC+2, steve.coleman wrote: > 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
Thank you very much 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f675acae-9f00-48df-99b3-59fda4a60e71%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
