General TC > Programming & Scripting - Unofficial
tce with comments + explicit path busybox applets, in future Tc14?
nick65go:
Thank you GNUser for info and Rich for script, I will look at it.
Like Hiro said, I have my balance, I draw the line (in the sand, but it evolves) about linux.
The 90% of my "needs" are covered by with fat-pigs like Xorg-3D + Firefox + LibreOffice + Vlc; and some light-weight tools (7Zip + Xfe + flwm + aterm). OK, I could shrink a little to gnumeric + abiword +mpv/mplayer, etc.
Then my focus shifted to security, which in never guaranteed, increase the cost, lower the speed execution.
So here began the try with VM (qemu) and low resources. Like take a "secured" kernel + modules (Alpinelinux, Ubuntu), add a [static] shell (toybox, busybox), a "compatible" libc / musl, and then happy use whatever apps are available as a shameless consumer.
One small problem was the package-manager for recursive dependencies. Most are [fast] pigs, or drag useless huge dependencies. Without care the final result will be as bloated as a win10. Purpose defeated as complexity means less security.
So, the new [naive] idea is to create a Virtual machine on-the-fly [all resources/pkg/tcz/deb are already present in the host, compacted], like Xen but much lighter, or like a single app restricted in a pseudo-container when internet connection is need [f**king Firefox piggy, I am looking at damn you]. So here is one of the TC strong points: applications with light dependency.
hiro:
"So here began the try with VM (qemu) and low resources. Like take a "secured" kernel + modules (Alpinelinux, Ubuntu)"
why not run qemu on tc, it seems more lightweight than alpine or ubuntu. i'm sure ubuntu is less secure bec. of all the preinstalled bloat.
"So, the new [naive] idea is to create a Virtual machine on-the-fly [all resources/pkg/tcz/deb are already present in the host, compacted], like Xen but much lighter, or like a single app restricted in a pseudo-container when internet connection is need [f**king Firefox piggy, I am looking at damn you]. So here is one of the TC strong points: applications with light dependency."
i'm not sure i understand. i guess you're making linux namespaces manually on tc?
nick65go:
@Hiro: To clarify, I indeed run qemu from TC, for now [trust the trustee].
-yes, the kernel is now from tc14 (in host and in guest machines), has all virtio drv. I used kernel from Alpinelinux to see all virtio drv dependency [lsmod /modprobe in guest] because they split out every possible module. And modules are SHA signed [yeah, with alpine keys, seen with modinfo]. The idea for a future guest-kernel build with ONLY the modules needed in qemu (size down from 5-7 MB to 2-3 MB ?). Toybox has one kernel ~= 2MB, but with old-drv.
- Ubuntu kernel only for host, in stand-by, tempting because has M$ secure-boot keys [signed].
- I did not understand very well Xen from wikipedia, or from their site/documentation; but I fetched the idea of using "templates" (like qemu hdd /snapshots) to build VMs on-the-fly. Plus it needs some CPU flags which my APU maybe does not have etc.
- Long story make short, I do not have much experience / knowledge with kernel (even after reading 100 of pages, too much info, maybe less brain / time / motivation).
-the virtual container LCX, docker, whatever seams complicated (more resource /libs, PAM kernel modules etc) versus layman qemu and/or chroot.
hiro:
--- Quote from: nick65go on February 26, 2023, 06:03:57 AM ---The idea for a future guest-kernel build with ONLY the modules needed in qemu (size down from 5-7 MB to 2-3 MB ?). Toybox has one kernel ~= 2MB, but with old-drv.
--- End quote ---
so you're thinking of excluding unused modules for security?
--- Quote from: nick65go on February 26, 2023, 06:03:57 AM ---- Ubuntu kernel only for host, in stand-by, tempting because has M$ secure-boot keys [signed].
--- End quote ---
so you want to allow microsoft to control what punk operating system you're allowed to boot? if you care about your privacy i wouldn't trust microsoft with anything. don't let them control you.
--- Quote from: nick65go on February 26, 2023, 06:03:57 AM ---- I did not understand very well Xen from wikipedia, or from their site/documentation; but I fetched the idea of using "templates" (like qemu hdd /snapshots) to build VMs on-the-fly. Plus it needs some CPU flags which my APU maybe does not have etc.
--- End quote ---
The main thing to note about Xen is that now is that in practice it's a Type2 Hypervisor like everything else now.
The main value is actually XCP-NG's management layer and GUI (XOA). It helps a lot if you have a whole fleet of hypervisors and need to remote-manage, migrate, failover, the VMs on them. Very good even for less experienced people or who doesn't understand the complicated qemu commandline syntax or the libvirt XML configuration complexities.
--- Quote from: nick65go on February 26, 2023, 06:03:57 AM ---- Long story make short, I do not have much experience / knowledge with kernel (even after reading 100 of pages, too much info, maybe less brain / time / motivation).
--- End quote ---
maybe just browse through all those options a bit in make menuconfig to get an overview of all the modules and where they are in that hierarchy.
--- Quote from: nick65go on February 26, 2023, 06:03:57 AM ----the virtual container LCX, docker, whatever seams complicated (more resource /libs, PAM kernel modules etc) versus layman qemu and/or chroot.
--- End quote ---
Here I fully agree, virtualization is much more involved on those lower layers, but it's such a clean abstraction that in practice it's much much simpler to manage. Both as developer and as user.
And bec. of some cpu extensions like vt-x and also paravirtualization it's not even much slower.
It's also easier to get right, but there's no way to eve get it properly secure, there's always side-channels no matter what you do.
nick65go:
@Hiro: Hi, thanks for the feed-back!
1. H: "so you're thinking of excluding unused modules for security?"
Yes, simplicity (eliminating not-used things) for me means less attack surface [less bugs], so more security.
2. H: "i wouldn't trust Microsoft with anything. don't let them control you"
Yes, fully agree! May I be forgiven, please; errare humanum est.
3. H: "if you have a whole fleet of hypervisors.."
NO. I am just a simple person with a computer, fooling around. I can understand the complicated qemu command-line syntax.
4. H: "there's no way to even get it properly secure".
Right! So simplification again, qemu stays. Too much (to learn /test) on my plates, for the time been.It is supposed to be fun, not part-time job.
As primitive protection I keep my private files on separate partition, hopping to not be mounted/ read by not-authorized software.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version