Michael Orlitzky wrote: > On 12/4/20 1:44 AM, Dale wrote: >> >> Will opentmpfiles be fixed at some point or is it true that it can't be >> fixed? On -dev, I think I read where one person said it can't be >> fixed. In that case, switching is likely a good idea since the insecure >> package can't be fixed. >> > > The answer is a bit complicated. The first thing we need to understand > that opentmpfiles is supposed to be a cross-platform (i.e. POSIX) > implementation of the systemd-tmpfiles program. Systemd itself only > runs on newer versions of linux, and since it has control of the > entire system, it can enable those non-standard symlink and hardlink > protections. So, > > * systemd-tmpfiles is secure, but only on linux, and only if you let > it enable fs.protected_hardlinks for you. > > The security there comes from two places. The first is that everything > was implemented carefully in C to avoid these problems, and the second > is that fs.protected_hardlinks solves the otherwise-unavoidable > hardlink exploits. > > Now for contrast, opentmpfiles is INsecure for two reasons: > > (1) It's written in shell script, so it doesn't have the ability to > pass e.g. O_NOFOLLOW to all of the calls that might follow > symlinks. And shell programs all operate on path names as opposed > to file descriptors, so race conditions are impossible to avoid. > > (2) The fs.protected_hardlinks sysctl is not cross-platform, so if > it's to fulfill its stated design goals, opentmpfiles can't rely > on fs.protected_hardlinks. > > The first problem is fixable, but the second is not. If opentmpfiles > is rewritten in C, it could be just as secure as systemd-tmpfiles... > but **only on linux with fs.protected_hardlinks enabled**. > > It will never be both secure and cross-platform. The design of the > whole tmpfiles.d thing is flawed in that regard. > >
So basically, that package would have to start over from scratch to be fixed. That's not very likely if history means anything. >> >> root@fireball / # sysctl -n fs.protected_hardlinks >> 1 >> root@fireball / # >> >> >> Does that improve things any or does that not really help anything? >> > > It completely fixes one of the problems (hardlinks), but does nothing > for the other (non-terminal symlinks). > > Sounds like switching is the best path and really, about the only path. Until something better comes along or the default is redone from scratch, not switching leaves a door open for a bad guy. Do you know if the systemd devs manage this or is this package done outside of them? Since some don't like systemd, myself being one of them, I'd like to know what group maintains that package. Thanks much for the info. At least now I have a better understanding of the issue. It gives me info to decide what is best and I hope it does the same for others reading this thread. Dale :-) :-)
