can not build cubes with qubes-builder

[ludwig...@gmail.com]

Hi all, I try to roll my own variant of an qubes install cd and it does not work to build with system.

In order to do so, I first try to get a standard qubes-os build environment up and running and it does not work!

I chose the 4.0 stable and did it according to the documentation on the web site.

The machine runs FC33 on bare metal with newest updates

How to get a build environment, that just works?

with install there were some problems with lib virt.

make qubes step fails.

-> Preparing fc33 build environment
-> Initializing RPM database...
error: can't create transaction lock on /home/build/src/qubes-builder/chroot-dom0-fc33/var/lib/rpm/.rpm.lock (Permission denied)
make[1]: *** [/home/build/src/qubes-builder/qubes-src/builder-rpm/Makefile-legacy.rpmbuilder:37: /home/build/src/qubes-builder/chroot-dom0-fc33/home/user/.prepared_base] Error 1

Any ideas?

Cheers,

Ludwig

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, one: https://github.com/QubesOS/qubes-issues/issues/6376
A workaround for now: disable SELinux.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmElNbAACgkQ24/THMrX
1ywZVQgAiLuxEQ4BtISQqMQe+hzoWW6bJszmSSsBvqsXjYvWZyw8RwPZZpF3+gEz
Gc5Tv/NEl2QR/cBCa8315xYOUP9XkLB8e9vQnvOf1pAKnRvrA/F8LtF3tLey8yMG
fgdxSVjRu6Y5qBXMewmipf8iKgveQ3rJYGg8FhtYj6N8N7SqCO7W5KZ/yfTROxJH
5GJLcJ+D9S3PzfJmiC0vRtpRJ/jB8YjAjxpIcsb/HmBBlhjY8yr4zOrR6gkn6hmv
D0CaKWIHud94J3DlOIGUNH/ofcaewa/M38zkrERbgMtNmOFd1lGFYjtxG83BhFkK
aVUlK5qQdSNSKWuzhu3pnof2q5FYFw==
=8oQj
-----END PGP SIGNATURE-----

[Steve Coleman]

If you want/need to keep sclinux installed and active there is a way for a novice to get past this kind of error pretty easily.

The selinux tool called "audit2allow" will scan the selinux avc logs and convert any errors found into ready to apply selinux policy files. Audit2why will just give you a simple explanation of the error itself. You can then (optionally) inspect the SE policy files and then finally apply the new policy file to your system to actually fix that error.

The biggest pain is that you need to do this incrementally for a build process as the build will only continue up to the next avc denial where the build will again fail, and then you do it again for the next error. Rinse and repeat as many times as necessary. Once you do get all the way through the build you should then just be able to 'make clean' and rebuild the binaries/packages/iso without any further issues. Someone really should collect all the policy files and make that available for those who might need it.

I used to have a script to do this almost painlessly but left that at work when I retired. It could probably even be added to the build process as a macro to trap the errors and apply the new policy and then continue the build, but I figure most people running qubes would much rather do it themselves since it is clearly a potential vulnerability if a hacker can get you to apply unrelated avc's. But then if the hacker is already on your system then you have even bigger problems.

One idea I was wanting to investigate years ago would be to use a selinux kernal as a security monitor within special high security vm's. One could set up the vm into the selinux permissive mode and then run a small rpc process to monitor the avc log, and send back notification if some rogue process accessed something they shouldn't. The hacker wouldn't know they tripped any alarms since the action was not actually blocked, and the qubes user would know imediatly about the intruder long before any kind of persistence was set up or data was exfiltrated. One could strategically create rules deliberately to signal that 'ls' or 'find' was used to explore certain parts of the system like /rw/usrlocal even if they used sudo to become root first. 

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/a44f9905-b9e5-4795-b9bf-5218bd6fffd0n%40googlegroups.com.

[ludwig...@gmail.com]

Hi all,

setenforce  Permissive

solved this problem for me. Thanks.

Now I have another problem:

3.x86_64.rpm
make[1]: Leaving directory '/home/build/src/qubes-builder'
[sudo] password for build:
[sudo] password for build:
Sorry, try again.
[sudo] password for build:
sudo: timed out reading password
sudo: 1 incorrect password attempt
*******************************************************************************
***                               ERROR                                      ***
*** Cannot create chroot because the current filesystem is mounted as nodev. ***
*** Build Qubes on a different filesystem, or run 'make remount' to remount  ***
*** / with dev option.
***                                                                          ***
*******************************************************************************
make[1]: *** [Makefile.generic:153: generic-prepare-chroot] Error 1
make: *** [Makefile:259: vmm-xen-vm] Error 1

make remount did not help.

the build system should be distributed as virtual machine if it is so sensitive, I feel.

How to heal this problem?

thanks alot,

Ludwig