Suggested access mode bits in /var/lib/softhsm about softhsmv2 HOT 9 CLOSED

The permission on the token directory is set by:

Each object file has its permission set by:

So we currently only allow the owner to access the files. Does the owner of the files match your user account?

from softhsmv2.

from softhsmv2.

Also, the token directory has its permissions set by:

The token and its objects are currently limited to the file owner. What permissions are you suggesting?

All user can set the environment variable SOFTHSM2_CONF and point to their own configuration file with a separate token directory.

from softhsmv2.

I propose to change the mode of /var/lib/softhsm/tokens to 1777:

• anyone can create token subdirectories directly under /var/lib/softhsm/tokens
• anyone can read the list of these token subdirectories
• only the owner of the subdirectory, root or the owner of /var/lib/softhsm/tokens (which would normally be root) can remove a token subdirectory
• this is the same regime as for /tmp
• setting this on install -d means that /var/lib/softhsm is auto-created (if needed) with 0755, so without sticky bit, and readable/accessible to all.

The softhsmtokendir-stickybit.patch.txt implements this facility.

With this patch, I succeeded in creating new slots (numbered --slot 0 on both) with softhsm2-util from both root and user account, leading to:

shell# ls -lR var/lib
var/lib:
total 4
drwxr-xr-x 3 root root 4096 Mar 31 11:01 softhsm

var/lib/softhsm:
total 4
drwxrwxrwt 4 root root 4096 Mar 31 11:03 tokens

var/lib/softhsm/tokens:
total 8
drwx------ 2 myuser myuser 4096 Mar 31 11:03 2c9ab123-7e34-8b69-d8a7-2dc565957f76
drwx------ 2 root   root   4096 Mar 31 11:01 6fe0cd4b-dd32-77ac-898a-b66da5ca37d8

var/lib/softhsm/tokens/2c9ab123-7e34-8b69-d8a7-2dc565957f76:
total 8
-rw------- 1 myuser myuser   8 Mar 31 11:03 generation
-rw------- 1 myuser myuser   0 Mar 31 11:03 token.lock
-rw------- 1 myuser myuser 320 Mar 31 11:03 token.object

var/lib/softhsm/tokens/6fe0cd4b-dd32-77ac-898a-b66da5ca37d8:
total 8
-rw------- 1 root root   8 Mar 31 11:02 generation
-rw------- 1 root root   0 Mar 31 11:01 token.lock
-rw------- 1 root root 320 Mar 31 11:01 token.object

Running this as the user, the token of root cannot be entered, though the directory 6fe0cd4b-dd32-77ac-898a-b66da5ca37d8 is shown:

shell$ ls -R var/lib/softhsm/tokens/*
var/lib/softhsm/tokens/2c9ab123-7e34-8b69-d8a7-2dc565957f76:
generation  token.lock  token.object
ls: cannot open directory var/lib/softhsm/tokens/6fe0cd4b-dd32-77ac-898a-b66da5ca37d8: Permission denied

shell$ rm -rf var/lib/softhsm/tokens/6fe0cd4b-dd32-77ac-898a-b66da5ca37d8/
rm: cannot remove `var/lib/softhsm/tokens/6fe0cd4b-dd32-77ac-898a-b66da5ca37d8': Permission denied

The one thing leaking here is that root has a token; but the hash is random (I presume) and reveals nothing; anything inside the directory is for root and root alone. This is the desired result.

I will comment on the other part(s) separately.

PATCH

from softhsmv2.

My proposal to use setuid/setgid on directories is not as helpful as I had expected. Only setgid is reliably implemented across POSIX systems.

Setting setuid would have avoided that root, when operating on a user's repository, could have introduced new files with new ownership. Alas, this will not work.

Setting setgid alone is possible, but its merits are limited since we do not, by default, create files accessible to the group, for security reasons. Setting the "setgid" bit on the directory would be useful when we would have been interested in group access to the token.

So, in retrospect, this part of my proposal is not as doable as I initially imagined. Sorry.

The impact of not adding setuid/setgid on the token's UUID-style directory name is that root may create objects that the user cannot access. The patch provided in my foregoing comment makes this visible.

from softhsmv2.

Are there anymore changes you would like to include or are you happy with #206 as a solution to this topic?

from softhsmv2.

What I would like to add won't make a portable solution, and so it should go. So what I propose is what is in this thread now, and nothing more.

from softhsmv2.

just noticed the ref to #206 -- yes, that makes me happy. thanks!

from softhsmv2.

Thanks, the code has now been merged.

from softhsmv2.