Something we don’t have yet here?
Doesn’t seem to have anything we don’t have.
Also, some systems don’t store the System.map file in /boot but in files such such as /lib/modules/*/*/System.map or /usr/src/*/System.map.
If we were to remove read access to kernel images in /boot for non-root users, then we’d also need to remove read access to files like /usr/src/*/vmlinux and /vmlinuz.
Instead of porting opensuse’s stuff to Debian, we can make our own simpler solution like Debian paste error
Config files would look like Debian paste error
Commented inline on github.
Really good approach.
(Although might have some nitpicks. mywiki.wooledge.org might say for line in $(cat ${config_file}) isn’t secure. Never mind. Please send a pull request. I’ll add any parsing enhancements on top.)
dpkg-statoverride should be used, though. Ideally as replacement for chmod/chown - if that is possible. But surely in combination with dpkg-statoverride. Because when packages are updated, these permissions will be reset- By using dpkg-statoverride, permissions will always be consistent what we want - even if packages are updated.
I was testing around with file capabilities and did some grep hackery to add a [Capabilities] sections where we can specify file capabilities.
What do you think of Debian paste error?
Example of a config file: Debian paste error
Would
while read line; do command; done <${config_file}
be better?
Should it also use a systemd service so these permissions are always set at boot regardless?
If users need to, they can disable the service or add a permission-hardening.d file for custom permissions.
It’s a good list, and as @madaidan said, Whonix implements pretty much all of it. We do not have separate partitions, but we restrict the permissions.With restricted root and the other Whonix protections, there is good security.
Probably better to add an optional 5th column Debian paste error
Example: Debian paste error
The advantage here would be we can just copy/paste the suse config file and don’t need yo modify it? Please add a source comment.
And then we could add our own config file in addition if we need to extend it?
if ! dpkg-statoverride --list | grep -q "${owner} ${group} ${mode:1} ${file%/}"; then
How would dpkg-statoverride update existing entries then if permissions changed in config? Maybe better to remove that line or improve of that’s feasible, not too much effort?
Could be. Considered bonus feature.
Not doable using systemd tmpfiles.d due to capabilities?
Sounds great!
madaidan via Whonix Forum:
Would
while read line; do command; done <${config_file}be better?
Yes.
I think it would be better to create our own.
You can’t update them either way.
dpkg-statoverride will fail with an error:
dpkg-statoverride: error: an override for '/bin/true' already exists; aborting
We’d need to make it remove the entry then add it with the new permissions.
If this line was removed, dpkg-statoverride would spam a bunch of errors.
## The permissions should not be reset during upgrades.
if dpkg-statoverride --list | grep -q "${file%/}"; then
## If there is an entry for the file, but the owner/group/mode do not
## match, we remove and re-add the entry to update it.
if ! dpkg-statoverride --list | grep -q "${owner} ${group} ${mode:1} ${file%/}"; then
dpkg-statoverride --remove "${file}"
dpkg-statoverride --add "${owner}" "${group}" "${mode}" "${file}"
fi
else
dpkg-statoverride --add "${owner}" "${group}" "${mode}" "${file}"
fi
This should allow us to update permissions.
while read line; do command; done <${config_file}
This isn’t working. It keeps empty lines which the script thinks are actual lines so it fails with
ERROR: File '' does not exist!
Dunno how to solve that.
I also need to find a better way of detecting if the mode is valid or not. Currently, it greps the output of seq -w 000 4777 but this isn’t good as it allows for some invalid modes e.g. 0692.
https://mywiki.wooledge.org/BashFAQ/001
but no worries about that one. I can change once first version is in git.
Could be added later if we figure that out.
It could look at each number individually and reject those which are invalid?
Might also not be too important as wrong permissions would throw error.
If a line is malformed, I’d say let’s use continue (i.e. show an error and skip that line) rather than break (stopping parsing, not parsing other lines).