Questions regarding use of tmpfs formatting and conflicts

Hello Kicksecure Community,

I have been researching tmpfs and optimal ways to mount places to it in my Kicksecure morph install without conflicting with anything like grub-live, systemd-fstab-generator, and swap-file-creator.
What lead me down this rabit hole was how someone in a “group chat” mentioned how they mounted their /tmp and their /.cache directories to tmpfs essentially making them in volatile memory given they don’t swap.

I dont believe I did it correctly which is leading me to ask here. While some of this might or might not be Kicksecure specific see fstab-vm bellow, I felt this would be a good place to ask since it seems like alot of security researchers and people that know better about linux are here. Who knows maybe this might help someone else or start a wiki entry about this topic.

Alrighty then, I first noticed a error message at boot which I thought at the time was a related conflict to booting into “Live Mode” but I tested that theory my booting normally and it showed both ways.

journalctl -b -p err | head -n 3

May 04 21:26:43 laptop systemd-fstab-generator[394]: Failed to create unit file '/run/systemd/generator/-.mount', as it already exists. Duplicate entry in '/etc/fstab'?
May 04 21:26:43 laptop systemd-fstab-generator[394]: Failed to create unit file '/run/systemd/generator/tmp.mount', as it already exists. Duplicate entry in '/etc/fstab'?
May 04 21:26:43 laptop (sd-execut[390]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.

cat /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=7908-0C4D                            /boot/efi      vfat    defaults,noatime 0 2
/dev/mapper/luks-90aa4338-82d9-4f48-97f1-ad86a6dfc4bf /              ext4    defaults,noatime,discard 0 1
/dev/mapper/luks-a3e63f9c-a3bb-4414-b1c4-f08ade4ca71d swap           swap    defaults,noatime,discard 0 0
tmpfs                                     /tmp           tmpfs    defaults,noatime,mode=1777 0 0
# .cache
tmpfs                                     /home/user/.cache           tmpfs    defaults,noatime,mode=1777 0 0
overlay / overlay rw 0 0
tmpfs /tmp tmpfs nosuid,nodev 0 0
  • Whats better?
    Is the duplicate entry line better for /tmp to tmpfs in /etc/fstab
tmpfs                                     /tmp           tmpfs    defaults,noatime,mode=1777 0 0

I distro morphed this install so I’m not sure what came with debian and what came with kicksecure.

Looking at fstab-vm file in the security-misc repository made me look into if that this the incorrect way to mount and confusion?

Looking at line #23 doesn’t seem right in formatting and why use bind in conjunction wouldn’t that not align with creating a new tmpfs instance?

tmpfs 							    /tmp 	      tmpfs     defaults,nosuid,nodev,noexec             0      0
  • ~/.cache mounted to tmpfs

What is better for mounting user cache to tmpfs?
Is it or rather would it be better to just mount /tmp to tmpfs then symlink ~/.cache to /temp

sudo mount -t tmpfs -o defaults,nosuid,nodev,noexec tmpfs /tmp && ln -s /tmp/.cache ~/.cache

Or should setting the XDG_CACHE_HOME variable to /tmp/$USER/.cache be better?

export XDG_CACHE_HOME="/tmp/$USER/.cache"

However don’t most apps not always respect the xdg spec always?

  • Can I have my cake and eat it too?

Can I have both the /tmp to /tmpfs and XDG_CACHE_HOME set without issue or is it unnecessary?

  • Issues related to “Live Mode” and encrypted swap with tmpfs mounts?

Is there any issue/bottleneck/conflicts with mounting .cache and /tmp to tmpfs with grub-live implementation?

If I or another user have these mount points is there gonna be existing issue when the times I might boot into “Live Mode”?

Distribution Morphing:

If non-persistent live mode is a priority, I don’t recommend distribution morphing.

Quote Distribution Morphing versus ISO - Differences:

  • Swap / mount / fstab related: Swap partition / swap files, mounts, /etc/fstab set up by Debian installer or the user are not disabled or modified during distribution morphing. This might be a concern for users interested in non-persistent live mode.

As distribution developers, it’s hard for us to control the environment in this setup.


ISO:

When installing using the ISO (or installing to hard drive by using the ISO installer), there should be no such issues. No need for any /etc/fstab modifications or anything.

(swap-file-creator does not run in live mode. (swap-file-creator, Live Mode))


In any case, live mode indicator systray should be pointing out if there are any disks mounted as read-write.


Did you perform a Functionality Test of Live mode and found unexpected persistence?


Recommended reading: grub-live, Security Considerations

First let me ask what is your use case for wanting to mount .cache to RAM?

What is better for mounting user cache to tmpfs?

I would say the fstab and reboot method.
The other method you mentioned you would prob have to rm and recreate the directory before you syslink it

Well since Live mode uses memory and you only have X amount RAM I would assume that half the amount of RAM would be used for the file system and the rest for free space. So it might reduce the RAM more?

1 Like

Makes sense I understand that. To further clarify what I mean and what I’m trying to understand is if I have XDG_CACHE_HOME=/tmp set and .cache mounted to tmpfs/tmp will there be any gotchas footguns or bottlenecks with Live Mode also?

It appears that grub-live dracut mounts half the system memory for system & home folders /run etc. then the rest of free space is the other half of RAM. If I boot into live mode and look at download directory it says somewhere around 5GB of free space and my total RAM is roughly around 12GB. I don’t think many users might know this about live mode.

This is also the same with Tails given you can’t download anything bigger then the free RAM available, around half is used in there implementation. Otherwise you have to select the persistent directory if you have it enabled to save files bigger since that directory is not in memory.

But onto the fstab-vm file line L23 that line doesn’t seem correct the line commited out below (L24) does look correct?

I also am no way implying that Kicksecure should mount or syslink .cache to tmpfs/tmp by default configuration.

Yes, and no I have not found any unexpected persistence with tests.
I will be installing via the ISO here though to look at defaults that are separate from distro morphing.

My use case is having certain applications like messaging apps and browsers store cache in RAM even when not in live mode so I things I’m working on still their while maintaining protection when communicating with randoms and online communities in public chats on messaging apps.

Really trying to not have to worry about people spamming weirdo sh*t or malware and my device saving these files just cause I joined a group chat or clicked open preview of something that someone shared in a chat.

Most applications are pretty good now in regards to not having auto previews turned on since its a security risk. Not all applications are made equally though. iMessage on iOS was exploited many times via auto-previews or links previews since it would auto download a image/file or a url link that would exploit a zero day. Not to mention someone could send you something illegal and it would be downloaded to your phone automatically, though this has been patched its still a concern with open source privacy based communications.

Thanks thats what I was thinking also. Syslinks might get corrupted or overided by updates too right?

Like when updating applications for example.

Many messaging applications stores files/avatars in .cache or follow the XDG env specifications. I will put this here but feel free to keep it or move it to another thread or use for wiki. Also if anything is incorrect though I researched this pretty well also feel free to correct it.


  • XMPP

Gajim client handles avatars and cached files shared or opened chats in ~/.cache/gajim/ following XDG Base Directory Specification

Dino (version 0.4.5 or later) client only caches avatars in ~/.cache/dino partially following XDG specifications.

Both Gajim and Dino have automatic previews turned off meaning that files shared in public chats are not automatically downloaded by the client simply by being in a public chat room.
The user has to specifically click on them to or prompt to download them.
Dino will auto download shared files in private chats, Gajim on the other hand does not.


  • IRC

Hexchat saves shared files in local Downloads folder typically.

Hexchat does not have auto downloads for shared images in IRC chats by default. However below is a defense in depth config to download files in RAM following the theme of this thread. Though its better advised to rely on “Live-Mode”:

# Directory for initial file downloads
## Default download location is ~/Downloads
# Save to .tmp if mounted to tmpfs
dcc_dir = ./tmp
## Save to ~/.cache
## Not needed if tmp is mounted to tmpfs or also cache is mounted to tmp and tmp is mounted to tmpfs
#dcc_dir = ~/.cache
## Toggles automatic removal of finished/failed transfers when set to 1
#dcc_remove = 1 
# Disable automatic opening for received files
## Asks for confirmation before downloading (default behavior).
dcc_auto_recv = 0
## Disables auto-opening for incoming file transfers.
#gui_autoopen_recv =0 

  • Matrix

Element client follows XDG specifications for caching shared files and avatars in ~/.cache/Element/

Nheko client typically caches shared images and avatars in the ~/.cache/nheko/ adhering to the XDG Base Directory Specification however I’m not sure if that is correct since its been ahile since I used this client.


  • SimpleX Chat

SimpleX Sends link previews by default and auto accept images is enabled by default as of v6.3.5 release.

It also appears they don’t follow XDG specification (atleast for the AppImage version)

Files shared/opened are stored here: ~/.local/share/simplex/simplex_v1_files

To make turn these settings off make sure you go to config ~/.config/simplex/properties check these lines are set:

PrivacyAcceptImages=false
PrivacyLinkPreviews=false

Chapter Put folder under Git Version Control might be useful so you can monitor which files actually change in the home folder.


Great!

Unsupported.