| 1 |
On 01/09/2018 07:07 PM, William Hubbs wrote |
| 2 |
> |
| 3 |
> However, I'm not sure how to deal with the hard link issue in a way that |
| 4 |
> will not break service scripts. |
| 5 |
> |
| 6 |
|
| 7 |
Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by |
| 8 |
default, but they have the liberty of requiring a relatively new Linux |
| 9 |
kernel. The larger problem there is that, unless you have some kernel |
| 10 |
protection built-in, the "Z" type in the tmpfiles.d spec is always going |
| 11 |
to be exploitable: |
| 12 |
|
| 13 |
* https://github.com/OpenRC/opentmpfiles/issues/3 |
| 14 |
|
| 15 |
* https://github.com/systemd/systemd/issues/7736 |
| 16 |
|
| 17 |
(I didn't realize at the time that the OpenRC fix still contained a race |
| 18 |
condition.) |
| 19 |
|
| 20 |
Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory |
| 21 |
that is not writable only by yourself and root. There's some precedent |
| 22 |
for this in e.g. |
| 23 |
|
| 24 |
https://wiki.gentoo.org/wiki/Hardened/Grsecurity_Trusted_Path_Execution |
| 25 |
|
| 26 |
where they refuse to *execute* something that is writable by others. But |
| 27 |
a solution like that would break existing scripts. |
| 28 |
|
| 29 |
If it's any consolation, the tools like chown, chgrp, chmod, setfacl, |
| 30 |
etc. are all vulnerable to the same issue themselves. GNU chown has the |
| 31 |
"--from" flag (which still contains a race, by the way), but the other |
| 32 |
tools don't, and are all exploitable in the same way. Again the advice |
| 33 |
seems to be "don't do things if somebody can write to the directory |
| 34 |
you're in." |
| 35 |
|
| 36 |
Here's a very tedious proposal for OpenRC: |
| 37 |
|
| 38 |
1. Create a new helper, called e.g. "newpath", that is like checkpath |
| 39 |
but only creates things, and doesn't modify them. |
| 40 |
|
| 41 |
2. Have newpath throw a warning if it's used in a directory that is |
| 42 |
writable by someone other than root and the OpenRC user. This will |
| 43 |
prevent people from creating /foo/bar after /foo has already been |
| 44 |
created with owner "foo:foo". In other words, service script |
| 45 |
writers will be encouraged to do things in a safe order. Since |
| 46 |
we're starting over, this might even be made an error. |
| 47 |
|
| 48 |
3. Deprecate checkpath |
| 49 |
|
| 50 |
4. Wait a million years for people to switch from checkpath to newpath |
| 51 |
|
| 52 |
5. Get rid of checkpath |
| 53 |
|
| 54 |
I'm not even sure that this solves the problem completely, but it's the |
| 55 |
only idea I've got left. |
Archives