Private Home Directories for Ubuntu 21.04 | Hacker News Reader

Private Home Directories for Ubuntu 21.04

ubuntu.com

110 pointsoedmarap95 comments

To me, user accounts have always seemed like the more reasonable approach to sandboxing vs. cloning the universe to run a single program in a container.

Most of my systems have a user for myself, and one or two other users like `sketchy` or `test` or something for programs that I trust enough to run, but don't trust enough to not fuck up my home directory in some way (including modifying startup scripts, which IMHO should probably require sudo to edit, even for a normal user).

If the program is really sketchy and you're worried about it doing something like exfiltrating ~/Documents/taxes, then private home directories would definitely seem like a good default. You can always have an explicitly shared area like /home/shared/$user that defaults to public.

Me too, I have on each system at least 6 users just for myself. I'm also an Ubuntu user at moment, and I change also the access rights for the home directory just for the user each time. I used SuSE before and they allways had just user access for the user.

I run such less trusted programs on other machines. The privilege elevation attack surface is just too big on a normal Linux system.

That's why I think intra-user isolation is better. I would feel so much better if my browser could just access its settings, the download directory, and read access outside my home directory (for libs and such).

Isn't SELinux supposed to provide exactly this functionality?

The tricky part are the profiles afaik. But this could be solved with some concentrated community effort I guess.

I think AppArmor does something similar (I don't know the differences to SELinux in detail, so if someone like to clarify please go ahead). I remember I've seen some AppArmor related stuff regarding Firefox (and LibreOffice I think) in Ubuntu. So seems not much is missing to have at least an sandboxed web browser out-of-the-box on a Linux desktop.

SELinux can and does do exactly this, depending on the configuration. What you'll most often see is that applications covered will have rules that allow it to access a subset of the user's home content (xdg cache, data, etc.) that allow that application to function, and SELinux will use UBAC rules to ensure that user A's instance of that application cannot access the data of user B's.

Profiles are indeed tricky though, and generally something I would consider more easily implemented as just logging in as a different user.

I can't speak much about AppArmor since I'm not too familiar with it.

SELinux can do this--think of it as a second layer of security that is checked after the normal DAC checks (e.g., process uid vs file permissions) succeed.

> I run such less trusted programs on other machines.

You could probably use Qubes OS instead.

I tried that for a while. Don't remember why I gave up, but it could have been abysmal youtube performance or laptop suspend issues.

It's been a while, though. But now I'm also spoiled with Sway. Haven't checked if I can keep Sway on qubes.

> I would feel so much better if my browser could just access its settings, the download directory, and read access outside my home directory (for libs and such).

I regularly have to both download files to other directories than my Download folder and upload files from other directories, such a restriction would break a lot of existing use cases.

The optimal way to achieve this would be to have the file / save picker a completely separate process, which then passes a token to the browser, which the browser then exchanges at some sort of "broker" process that returns a handle to the file.

Easiest way to do it is to install via Flatpak, e.g. for Chromium with only access to the Downloads directory:

  sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
  sudo flatpak install -y flathub org.chromium.Chromium
  sudo flatpak override org.chromium.Chromium --nofilesystem=home --filesystem=$HOME/Downloads

Agree, users are a good start, also systemd for example provide ways to run a process on its own file system too, readonly, etc... I guess virtualization or containers is needed because of the unknowns bugs, bad use of technology and /or not being able to harness a system very well with non sandboxing methods.

This is just changing the default permissions on a home directory -not a more complicated encrypted/systemd setup I thought it would be.

Way more background than I expected for such a seemingly minor change.

Even if it's minor, this is an excellent article because it accompanies the change with clear instructions on how to fix suspected issues or to revert the change, in a manner that even a relative layperson on a Linux system could follow.

I totally thought they were turning on homed with encryption by default, and was _super_ excited. I've been toying with doing that myself and having someone go first would be great.

If this encryption is still the same as it used to be a couple of years ago (encfs, IIRC), it's good they aren't. I stumbled on that multiple times before I learned not to turn this shit on. Every time on a new installation (which doesn't happen that often, so it's natural I was forgetting) I chose "do encrypt" option (because why not?), it was working perfectly fine long enough for me to settle in, and then one day I would be downloading some books via torrents, and torrent wouldn't proceed because of "filepath too long" (which was very confusing, because how could that be on Ext4, given it's perfectly fine for other peers, who must be on NTFS, most likely), and I had to spend time disabling encfs (I guess it wasn't that easy either: creating a new user was the quickest option) in order for things to start working.

So, finally I learned just not to use file-based encryption, except for minor stuff like dropbox directory.

That's a shame. Honestly though, full-disk is just so darn easy, and nearly as secure. I'll probably just stick with that for a good long while.

EDIT: Looks like LUKS is supported now, which is nice:

https://wiki.archlinux.org/index.php/Systemd-homed#LUKS_home...

Full disk encryption is more secure. If you can't trust your system files who knows whats happening when you enter your password.

Isn’t Secure Boot supposed to solve that issue?

How can Secure Boot help against, say, patched libc?

You need either full disk encryption, or something like dm-verity for that.

I misunderstood your post. Of course full disk encryption is vital for security. My point was that without secure boot you can't be sure that software asking for your password is legitimate. Typical setup consists of unencrypted boot partition with Linux kernel which asks for password. You can't be sure that this Linux kernel was not patched, but Secure Boot helps to ensure that.

i had the exact same thought. i was diving into this with popcorn in hand thinking this is what it was about. i can't remember the scope of this but i remember reading about it sometime ago--regardless, if this was indeed systemd, it would have been the nail in the coffin for me to go full freebsd.

I have "umask 077" in my ~/.bash_profile.

Makes sense to me, but I'd be much more excited to go back to not having the snap directory shoved in my face.

I’ve heard good things about pop os. Have you tried and liked any of the others? It was a bit unnerving to have my Firefox windows change all of a sudden due to upgrade.

Pop OS is great. I've used it when I need a laptop to Just Work quickly, and I have a non-technical family member who has been using it for about 2 years now with zero issues.

Pop OS is great. Of course I had some issues with UEFI stuff (since they don't use GRUB) but their website had great tutorials for NVMe SSDs. And you have flatpak instead of snap (so no snap folder in your case). But most importantly, they have a killer tiling extension for Gnome. It is superb.

Pop OS also has a great WIP tiling wm if you want something that doesn't require you to replace all the other creature comforts like sway or i3.

Its not perfect but there are some ways to hide it during normal use.

1. Create a file in your home called .hidden with one line "snap" to hide it in the file browser.

2. You can add --hide=snap to your ls alias to hide folders by that name.

I use ubuntu and have disabled everything snap related. Works well.

How do you install apps only available in Ubuntu as snaps?

I don't know of any. I do use flatpak whenever I can.

I left Ubuntu because of snap - and I don't see myself going back. It's funny, I feel like eventually every distribution has to do something to irritate long-term users, but endear themselves to others. It's part of a weird growth phase.

What distro do you use now?

Currently I'm on Manjaro. I went through my post-Ubuntu cycle and looked into Gentoo, Mint, Solus, and FreeBSD again. Basically Manjaro made running Arch painless. I'm happy enough for now.

Interesting cos I been looking at manjaro, kde flavour. Bit tired of all the little bugs in ubuntu. Wanted to try arch.

Give it a go. Worst case, VM it. That's how I did my evaluations.

Shoved it on my laptop, killed off the kubuntu partition. Man it’s so much better. No screen tearing out of the box!!! Just works.

Tho I cannot get proper VS Code installed :/

Install yay, and then use it to manage vscode. I rely on the AUR.

I personally don't use it, and was born barely before its first release, but I believe Slackware is just as it ever was..

I wish such announcements would include a reference to the bug tracker where the change was discussed:

https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734

This could be simplified to https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734 is fixed.

Even Ubuntu's calling Linux home desktop 'quaint' now..

Well to be more precise they're saying that "use-cases like multiple family members sharing a single PC" are quaint - by contrast with "the modern era of cloud computing and IoT". A charitable reading would perhaps count it a fair observation that an increase in computing ubiquity has led to most machines, even workstations, being single-user.

Tl;dr home directories now default to 750.

While the change makes sense, it's going to be a massive headache to fix all existing software that runs as its own user when upgrading.

Too bad Red Hat is going the opposite direction with their Toolbox container management project, sharing your entire home dir with every container but not explicitly documenting this:

https://github.com/containers/toolbox/issues/183

I remember a while ago, Ubuntu used encryptfs for home directories, but it was removed. Weird, because I thought it was a great idea

I’ve been using fscrypt to encrypt my home directory for over a year now and it seems to work fine: https://wiki.archlinux.org/index.php/Fscrypt

Thanks for that... I’ll check it out

BTW: The only issue I‘ve come across was that the pulseaudio user daemon couldn’t initialize during login (because it started before fscrypt unlocked home dir). There is an easy workaround for Ubuntu 20: https://github.com/google/fscrypt/issues/270

Hi! Author of fs-crypt dropping in from the interwebs.

I also created eCryptfs, which was Ubuntu's original home directory encryption technology, with lots of additional distro integration work by Dustin Kirkland. Unfortunately I had to make some compromises when going with the stackable model, and that caused some problems.

I took the lessons I learned from that first attempt and created fs-crypt as a sort of atonement. I think I got a lot more right on my second attempt at file-base encryption in Linux. At least, it's good enough to be the technology that now encrypts Android storage.

The problem with Linux supporting stuff forever is that some things really need to be retired once a better solution has come along. However so long as there are eCryptfs users out there, I don't think it's going to ever go away at this point.

Thanks for all the great work on both 'ecryptfs' and 'fs-crypt'!

Around 16.04 if you enabled encryption during installation, you got ecryptfs home directories - later (18.04?) they changed to encrypting the entire disk.

In some ways, encrypting the entire disk is more secure.

On Ubuntu, you probably want zfs native encryption - either full disk, or per user:

https://talldanestale.dk/2020/04/06/zfs-and-homedir-encrypti...

Hope general zfs support will improve in the installer, though. As well as automation and tooling around automatic snapshots.

Isn’t this what Windows has done by default for a while now? Every user’s home directory is private to that user.

It is in fact an simple change to UMASK in /etc/login.defs. The default value is different between various Linux distributions and in fact Unix systems as a whole depending on the "pedigree". On the multiuser systems the default tends to be 022 (ie. 755 permission bits => read and execute to everyone), on "internet server" systems 033 (ie. execute to everyone, such that finger and http://foo.bar/~quux/ works) and 077 on workstation unix systems (ie. $HOME is completely private). And I have strong feeling that the whole story about "systems shared by family" is just PR spin as that setting is simply default in upstream Debian...

Well that supposition can be checked easily...

    $ dpkg -S /etc/login.defs 
    login: /etc/login.defs

https://packages.ubuntu.com/login -> hirsuite -> changelog gets you to https://changelogs.ubuntu.com/changelogs/pool/main/s/shadow/... where you can see this is an ubuntu-specific patch introduced in version 1:4.8.1-1ubuntu8

> This change now means that in the future if an attacker were to exploit some previously unknown vulnerability in a given system service that is running as a separate user, they would then not be able to access the data of any other user (both human or system service) on the system.

If the attacker can already access arbitrary files on your box, I don't think simple unix permissions will save you

So let's just set everything to 777? /s

All I am saying is that security is like onion layers, and unix permissions are the last layer probably. If the attacker penetrated through all the other layers, chances are that unix permissions will not save you.

google.com/search?q=defense+in+depth

Former pentester here. It was often the case that we were able to penetrate a box as a low-level user account, and the way we escalated was to search ~/.bash_history of an admin account.

chmod'ing the homedir would've prevented that. Unix happens to be pretty good about directory permissions.

The .bash_history file is mode 0600, regardless of directory permissions. Was this not always the case?

Heh. Looks like I’ve been out of the game longer than I thought. It’s suddenly been 6 years.

Welp. Yes, I misremembered that specific example.

Still, you’d be amazed how often people leave json credentials in their homedir that can be used to pivot to e.g. S3.

The number of bash history files with accidental passwords pasted into them is quite high.

Another reason I don’t sudo and instead ssh

Shell history files for admin accounts should be disabled (or at least kept short) for this reason.

But I really really like shell history files if I have to come behind someone!

Interesting idea - make it so all your passwords start with the same four characters (say Ab54) - (it's hard to get good passwords you can safely type at a prompt anyway) and then have a script that searches your history/log files for strings beginning with the Ab54 characters and replacing them with XXXX or similar.

All sorts of horrible side effects can immediately be identified.

That's what they are for, though.

Ubuntu should develop shadow accounts - the user will log in to a completely different account of the same login depending on password. That is if someone forces you to log in you could use different password and pretend it is your stuff.

Just create second account. This feature you describe is needed like to one in a million users.

True, Not many actually need it. A 2nd account with all the disk space would raise some questions

Then again checks foil hat, that’s what you want us to believe ;)

You dont need it now but in the future it could be crucial to have some enclave of freedom. Also when the drive is encrypted it is not possible to tell how much data it really contains.

Second account will have a different login so when referenced with other metadata it may tell that it is not in fact your main account. Not sure why people are opposed to measures that increase privacy?

> Not sure why people are opposed to measures that increase privacy?

Because small increased of privacy should not result in huge usability decrease.

This is already the case with systemd-homed.

Reply on news.ycombinator.com