Fossapup Remaster with recompiled kernel

[Chrysolite Azalea]

Hello everyone! I've created a Fossapup remaster with several enhancements.

What has been changed:

1. The new kernel has been compiled (5.15.4) with AppArmor and Landlock support
2. New software: AppArmor userspace utilities and Bubblewrap -- the unprivileged namespace sandboxing tool
3. run-as-spot script has been modified, so it doesn't simply switch to an unprivileged user, but also confines the app with Bubblewrap and AppArmor profile. This prevents the browser from reading root's home directory, for example.\
4. Securityfs is now automatically mounted (required for AppArmor userspace tools)
5. /proc is now mounted with hidepid=2

What is planned:

1. Automatic loading of AppArmor policy (currently, only spot confinement profiles are loaded by run-as-spot)
2. Seccomp support in run-as-spot (I didn't write the filter yet) DONE
3. Currently, run-as-spot sandbox doesn't allow creating nested namespaces due to AppArmor capability prohibition. I plan to allow it when I'm sure it's safe, but apps can still confine themselves further with Landlock
4. Replace iptables-legacy with iptables-nft DONE
5. Research the possibility of using Wayland or nested X servers in order to prevent abuse
6. Research the possibility of using xdg-dbus-proxy
7. Research the possibility of using the Landlock security module

Download link

The iso above is not thoroughly tested and may have issues, so there are files for Frugal install:

Download link

[Chrysolite Azalea]

I'd like to mention, I've only tested it in the QEMU, I've never tried to run it on bare metal.

[dimkr]

1. The new kernel has been compiled (5.15.4) with AppArmor and Landlock support
2. New software: AppArmor userspace utilities and Bubblewrap -- the unprivileged namespace sandboxing tool
3. **run-as-spot** script has been modified, so it doesn't simply switch to an unprivileged user, but also confines the app with Bubblewrap and AppArmor profile.

Interesting stuff. I think you'll be interested in new security-related features in woof-CE:

https://github.com/puppylinux-woof-CE/woof-CE/pull/3419
https://github.com/puppylinux-woof-CE/woof-CE/pull/3484

Feedback and more ideas are welcome! I'm evaluating the option of adding another layer of sandboxing using seccomp, but not 100% sure what to block and why.

[Chrysolite Azalea]

That's nice. However, I think that Landlock is a way for already sandboxed apps to further restrict themselves. For example, a browser might want to prevent itself from reading anything other than its own directories, and the downloads directory. Since run-as-spot usually runs as root, it can make use of privileged sandboxing tools, such as AppArmor and namespaces.

[Chrysolite Azalea]

I've made some changes

(since the last ISO I've made worked on QEMU, but I couldn't boot it on bare-metal, I'm publishing this one in form of SFS files, vmlinuz and initrd.gz kit -- you can create a frugal installation and put these ones instead of standard ones)

What has changed:

• The firewall now uses nf_tables instead of legacy iptables interface

What I have tried:

• Enabling Lockdown during initialization -- this has failed, because it breaks the X server and firewall. It seems that Puppy Linux doesn't load all kernel modules during boot and initialization, and something is loaded while system is completely running, so, before enabling Lockdown, I'll have to figure out what's being loaded and put it in the init
• Enabling AppArmor for the init process -- I'll figure it out later

[mikeslr]

Echo dimkr's "interesting stuff". I've downloaded your ISO replacement files and will set it up on bare metal. About ISOs. They can be tricky to create and are not really needed unless and until your are ready to 'publish for everyone'. And even then there are alternatives. In the meantime, if you place all needed files in a folder --with an appropriate name-- JakeSFR’s packit, viewtopic.php?t=6868 you can package the bunch as a tar.gz for others. [IIRC, although this app can create an ISO, it's not boot-able].

With web-browsers 'locked out' of one's system, you may want to consider adding Mike Walsh's permission-changer. Essentially it's an app where by the user uses rox running as root to copy files into spot's upload folder and out of spot's download folder, changing permissions during the transfer. Be back in a couple minutes with the link. See this post and the link to MikeWalsh's latest version: https://www.forum.puppylinux.com/viewto ... 087#p55087

[mikeslr]

Can confirm that your current version boots to desktop. I'm posting from it now using an external 'portable-palemoon'. Will examine things more closely tomorrow.

For now, just this suggestion. You've copied 666philb's approach of locating many applications in an adrv.sfs. If you continue with that system I suggest that you change the name of that file-system to ydrv_fossapup64_9.5.sfs. Both ydrv.sfs and adrv.sfs will be copied into RAM on boot-up. But adrv.sfses have priority in the merge-file-system; i.e., their contents will over-write the contents of ydrv.sfs. I recommend adrv.sfses only be used for applications --such as web-browsers-- which will often have to be upgraded. amethyst's NicOS-Utility's Save2SFS can create/work with either. https://www.forum.puppylinux.com/viewto ... 983#p12983.
Edit:
However, while that is the best long term use of an adrv, while developing and testing, you can quickly (it takes less than a minute) incorporate changes into an adrv, substitute the new adrv for the old and reboot. If you decide to keep a change, you can re-run Save2SFS incorporate the adrv into the ydrv reboot and again use the ability to create a new adrv in further testing.

My other, more taxing suggestion, would be to consider using dimkr's VanillaDpup as the base for your explorations. That would make it easier for him to provide technical advice; and the resulting Puppy would have access to repositories for a couple more years.

[mikeslr]

just to note the edit in the previous post if you read it before I included the 'after-thought'.

[ally]

mirrored here:

https://archive.org/details/puppy_linux_-fossapup64

[mikeslr]

Some early notes:
Again posting from external-portable palemoon NOT running as Spot.

The only things I've done are to rename adrv to ydrv --see previous post-- and reboot creating a SaveFolder. Added some icon themes, a new background and use jwmDesk to customize the desktop. [Don't want to get carried away and install anything likely to interfere with AppArmor and Landlock}. Updated Quickpet and rebooted.

The first thing noticeable -- even before the above changes-- is that firewall is turned off and there doesn't appear to be a way to turn it on.

I used Menu>Setup>quickpet to install Chromium. [It's version 83 which doesn't auto-update. Will have to figure out how]. The terminal reported the following on completion of the install.

Installing chromium.png (102.26 KiB) Viewed 1840 times

During the install and thereafter while running Chromium, Chromium, itself, provided a normal display but the desktop background and everything else flickered constantly.

Chromium Opened(1).gif (354.61 KiB) Viewed 1840 times

Restarting-X seems to have resolved that.
Oh, yah. Installed Take-a-gif, https://www.forum.puppylinux.com/viewto ... 953#p67953

[mikeslr]

I'll have to read-up about Armour. It does not appear that its restrictions take effect by default. Using the Chromium installed (see last post) I was able to download files other than to the /Spot Folder, see files on a mounted partition of my hard-drive

Chromium-Sees Files.png (57.2 KiB) Viewed 1644 times

and can open them.

Chromium Opens Files.png (131.49 KiB) Viewed 1644 times

[Although Chromium doesn't have a menu listing to open files, Ctrl-o will bring up a gui].

FYI, so far the only ways under "Puppys" I know about to avoid ALL the above (spot does limit download locations) is to run applications either in a container ala EasyOS or in a Chroot. Browser in a Chroot can only see what's in RAM. Running web-browsers located in /home/spot as spot, IIRC, precluded uploads/opening/ files and starting applications but not the viewing of the names of files on an already mounted drive-partition; i.e., it could see what was there but not do anything with it.

[Chrysolite Azalea]

I'll have to read-up about Armour. It does not appear that its restrictions take effect by default. Using the Chromium installed (see last post) I was able to download files other than to the /Spot Folder, see files on a mounted partition of my hard-drive

Because this remaster doesn't offer any automatic profile-loading mechanisms other than run-as-spot (which only loads spot and sandbox profiles to transition before running an app). However, you can manually load a profile with apparmor_parser and run an app under it with aa-exec.

[Chrysolite Azalea]

A new kernel has been built.

[Chrysolite Azalea]

Hello everyone! I've made a new remaster. What has changed:

1. Since the 5.19 kernel reached the end-of-life, I've switched to the long-term 5.15 kernel
2. run-as-spot now loads a basic deny-list seccomp filter that blocks the most dangerous system calls
3. The init process is now run under a permissive complain-mode puppy_init AppArmor profile. It can be used later to enhance security. It's not restrictive, and any process run under it can always switch to the unconfined profile
4. Basic firewall rules are now loaded at boot. They don't deny anything, just log the violations
5. After all kernel modules are loaded, the boot script enables Lockdown in Confidentiality mode
6. I've compiled LXC for this remaster, but I haven't fully tested it

What is planned:

1. Compiling Cage with Xwayland support in order to provide X server isolation. run-as-spot would block access to the normal X server and only allow display access through the new instance of the Wayland composer
2. Compiling xdg-dbus-proxy in order to prevent unwanted D-Bus access

Download link

[mrjake2]

I'd really like to get this working as the base Fossapup64 doesn't have the kernel config needed for my laptop keyboard. Everything is working with your kernel here EXCEPT wifi. I've been banging my head against it for a while now, and I think it has something to do with the new security features you enabled. If I use unencrypted wifi it works fine. However if I try to use WPA2, I get the following message in dmesg:

wlan0: Lockdown: modprobe: unsigned module loading is restricted

So it seems that the wifi manager is trying to load some module post-boot, that is failing, and then that prevents wpa_supplicant from being able to connect (it reports that it is a psk failure, but I know that's not the case as I use the exact same config for other linux distros on the same hardware).

Any idea how to troubleshoot this further? Note that in the above, it doesn't tell me the module it is trying to load so I'm not sure how to figure that out (or if it's relevant to solving the problem).

[mrjake2]

Giving an update on my previous post. I was using the files in the "next" folder in the share from post #1, which as of this writing are the files from 11/22. I switched over to the files in the root of the share dated from 10/22 and now wifi is working as expected. Keyboard, too.