DarthYoshiBoy

Attributes only apply to the directory’s own allocation table and child directories have their own tables.

Thanks. It has been a while, but I was fairly certain that this was the case, glad to have the confirmation. 👍

If you’d like to look into it further. the +i flag in chattr is setting an attribute making the file (everything in Linux is a file, so yes this even means directories) immutable. When a file is immutable, it isn’t possible to change the ownership, group, name, or permissions of the file, nor will you be able to write, append, or truncate the file.

It’s been a while since I’ve used it, but I don’t believe it’s possible to have an immutable directory where you can still modify the contents therein, but I may be misremembering that. It would seem unlikely since adding content to the directory should require that you modify the links for the directory, which shouldn’t be allowable with an immutable object?

It’s possible that the +a chattr attribute may achieve what you’d prefer. I believe that flag will make it so that files (and again, everything in Linux is a file) can be created and modified, but never deleted. I’ve actually never used this one, but I can foresee how this still may not be ideal for your wishes since updates to games may expect to be able to delete old content which would be thwarted here. 🤷

I’m now deeply curious if it works for your use case. Hit me back if you give it a go and let me know if it works out or not.

If gaming with Nvidia hardware is your primary concern, then maybe Bazzite would suit you. It’s based on Immutable Fedora, with tweaks to give it a SteamOS like experience. It offers Gnome or KDE for the desktop, and supposedly has everything dialed in for gaming. I’ve heard a bunch about it doing great with Nvidia cards and gaming in general, I suspect that you’d be able to do everything else you might need via the desktop it provides, but I have no knowledge of how it handles multiple monitors so maybe therein lies the fatal flaw.

If you use a fancy official VPN client from Mullvad, PIA, etc, you won’t need this since most clients already have a kill switch built in (also called Lockdown Mode in Mullvad).

According to the researchers…

The result of this is the user transmits packets that are never encrypted by a VPN, and an attacker can snoop their traffic. We are using the term decloaking to refer to this effect. Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.

Killswitches are insufficient protection since the TunnelVision attack never disables the VPN tunnel. The TunnelVision attackers are instructing your physical layer connection to route everything through a node of their choosing rather than killing your VPN connection, and since the VPN connection never drops, a killswitch will never engage. The VPN stays up, thinking it is doing a good job, but in the meantime your network interface has been instructed to route no traffic through the VPN and instead route everything to the location of the attacker’s choosing. I have heard that a couple of VPNs think their clients are not vulnerable here, but I haven’t seen independent conclusive proof one way or the other yet.

I suspect that your “Solution” also fails to mitigate the issues in TunnelVision because it allows LAN access to the physical interface. In a TunnelVision attack the hostile has to be on your LAN (or rather the same LAN you are on since I suspect that “The coffee shop wi-fi” is the more likely network for an attack like this) already, so if they’re going to tell your interface to route traffic somewhere else, in all likelihood that somewhere else will already be in the same LAN you are and their exfiltration will be allowed under your configuration.