Strictly speaking, you can already configure this easily via systemd.services.*.serviceConfig.PrivateTmp.

clamd will naturally be a juicy target, it seems more prudent to never let it see any of the fs, only consuming bytes over a pre-opened file descriptor & sending judgements about those bytes to another fd, or some other configuration where it runs completely "blind" (probably should run on a dedicated machine, even).

If the motivation is only to share files/whatnot with another daemon, you could try making them share namespace(s) or something. That seems stronger than exposing the system /tmp.

I'm assuming using systemd.services.*.serviceConfig.PrivateTmp is a bad idea, as it makes the configuration depend on internals of modules.

As for clamd being a juicy target, I completely agree with you. Had there been an actually strong protection of the filesystem, I wouldn't even have considered this. But protecting only /tmp means a whole lot of the filesystem is exposed, so I'm a bit doubtful this has a real use.

Then, your comment made me notice the JoinsNamespaceOf parameter, so I guess I can get clamsmtp work otherwise. That said, eg. clamdscan /tmp/foo won't work, which is surprising to beginners (TBH, it took me an hour with help from #clamav to understand why clamscan worked but not clamdscan, not counting the time I spent debugging before this: /tmp is a logical place to put test files), so I'm leaving this open so that if it's merged at least an option will be put forward in the documentation and people have a chance to more easily get what's going on. :)

Hmm, actually I just tried adding 7a711db to the daemon that runs clamdscan and run clamav with PrivateTmp enabled, and I'm hitting the same issue of clamsmtp not being able to pass files through clamdscan via /tmp, even after having manually restarted both services.

Did I miss something?

But protecting only /tmp means a whole lot of the filesystem is exposed, so I'm a bit doubtful this has a real use.

My comment was more to suggest going in the opposite direction of this PR, i.e. add more not fewer restrictions, I didn't intend to say that we should not merge this in the interim, if there's a need for it.

In this case I completely agree with you, but maybe patch clamdsmtp so that people know it has a rather peculiar way of working due to the hardening in place?

Actually, I guess that's about the same as most hardening, it's a trade-off between usability and security. I personally deem linux's DAC enough for security and believe that *ns bring in more risks than benefits, but that's just my opinion :)

believe that *ns bring in more risks than benefits

I think history proves that ns will never be enough and sometimes can be a liability. A skilled & motivated attacker will "simply" target the kernel if they have to, after all. Perhaps it is a mistake to rely on ns for anything beyond deployment convenience, but lots of people seem to think you can enhance security this way. I'm not qualified to say either way but am hopeful that it helps more than it hurts overall :)

I've integrated 4314be4 but closing this for now