Unsafe adduser default permission for /home/$USER

K

kalevik

Hello!

I just realized that adduser has created my users with 755 /home/$USER permissions.

I fixed them to be 700 and ran adduser -C to create /etc/adduser.conf with a safe default 700.

Is there any chance to get 700 as a default without having to create /etc/adduser.conf?

br,
Kalevi K
 
kalevik said:
[…] I just realized that adduser has created my users with 755 /home/$USER permissions. […]
Click to expand...
This is u=rwx,go=rx so a daemon can access e. g. ~/.ssh/authorized_keys (see ssh(1) to learn about its significance). Permissions must be granted along the whole pathname traversal. Of course, a better – not best – solution would u=rwx,go= and use Access Control Lists to furnish the rights.​
kalevik said:
Is there any chance to get 700 as a default without having to create /etc/adduser.conf?
Click to expand...
I’m afraid not. I suppose the idea is that “it works” without mandating that you were some kind of FreeBSD guru already.​
 
Kai Burghardt said:
This is u=rwx,go=rx so a daemon can access e. g. ~/.ssh/authorized_keys (see ssh(1) to learn about its significance). Permissions must be granted along the whole pathname traversal. Of course, a better – not best – solution would u=rwx,go= and use Access Control Lists to furnish the rights.
I’m afraid not. I suppose the idea is that “it works” without mandating that you were some kind of FreeBSD guru already.​
Click to expand...
Hi Kai! I do not understand. My home directory on FreeBSD 15 is now 700. I just created an SSH keypair on my Fedora 43 laptop using ssh-keygen, then copied the newly created public key to FreeBSD15 ~/.ssh/authorized_keys. I was able to login using public key with this command:

ssh kalevi@fbsd15.local -i /home/untosten/.ssh/id_ed25519

Using "truss -p 82586 -f -o foo", I verified that the SSH daemon does this:

root@fbsd15:~ # grep authorized foo
52964: fstatat(AT_FDCWD,"/home/kalevi/.ssh/authorized_keys",{ mode=-rw-r--r-- ,inode=42500,size=108,blksize=4096 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
52964: openat(AT_FDCWD,"/home/kalevi/.ssh/authorized_keys",O_RDONLY|O_NONBLOCK,00) = 8 (0x8)
52964: __realpathat(AT_FDCWD,"/home/kalevi/.ssh/authorized_keys","/home/kalevi/.ssh/authorized_keys",1024,0) = 0 (0x0)
52964: fstatat(AT_FDCWD,"/home/kalevi/.ssh/authorized_keys",{ mode=-rw-r--r-- ,inode=42500,size=108,blksize=4096 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
52964: openat(AT_FDCWD,"/home/kalevi/.ssh/authorized_keys",O_RDONLY|O_NONBLOCK,00) = 8 (0x8)
52964: __realpathat(AT_FDCWD,"/home/kalevi/.ssh/authorized_keys","/home/kalevi/.ssh/authorized_keys",1024,0) = 0 (0x0)


So I am wondering what is the real rationale behind the 755 permissions.
 
The idea that 700 for a user's home directory is automatically more safe than 755 is dubious, or even faulty. It depends on how the system is set up, and the usage pattern.

To (a): One style of configuring users is to take all people in a "work group" (the ones that need to share file) and give them the same group ID. In that style, having a default of g=rx (the 5 in the middle of 755) is sensible. A different style is to say that any user has their own group (and some Linux distributions today create a group per user, with the group name identical to the user name), which makes the group permissions irrelevant, since no two users are in the same group anyway.

Related to this is the question of how many people use a host. Today, the vast majority of all "daily driver" systems are single user, and there the whole idea of users and groups becomes silly. In such a system, we really need only one bit to describe the whole permission system: is this file or directory modifiable by the one human when running in unprivileged mode, or not.

The tradition of Unix systems comes out of shared servers, used both to run services (e-mail, DNS, file storage accessible over the network), and as a (CLI) login host for many people. Those many people are traditionally separated into a small number of groups, such as engineering, marketing, and finance. In such a system, default permissions of 755 make sense (as does 750).

If one sets the default to 700 on a multi-user / multi-group system, and then the users need to share files anyway, that probably does not make the system more secure, since it forces users (who are often not skilled) to change permissions themselves, and may do dumb stuff like "chmod -R a+wx *" in their home directory. In such an environment, it is better to give users sensible defaults, to reduce the temptation that they change thing.

And ssh and sshd do check permissions of critical files (such as keys and authorized_hosts) and the ~/.ssh directory anyway. So the permissions of the home directory matters little.
 
Changing default on FreeBSD project side could confuse admins with unintended different behavior per-user (newly created user at some point has different default with others).

Long standing, "not only for hobbies" OS like FreeBSD needs several major releases to repeatedly notify admins to prepare testing with quite intensive and wide-spreaded levels not to break "the organization's $work" (fix or workaround for everywhere needed) and announcements to users they manage of forcible permission changes.

On the other hand, newly forked "distros" can have different permissions "from start" freely. I believe, so derived HardenedBSD from FreeBSD.
If I understand/recall correctly, discontinued TrueOS (former PC-BSD) had some different defaults with system tunings to target desktop use-cases.
 
You must log in or register to reply here.
Back
Top