Renaud Allard <[email protected]> wrote: > On 3/16/21 4:11 PM, Theo de Raadt wrote: > > Renaud Allard <[email protected]> wrote: > > > >> This is a small patch to try to add a basic pledge() to exim. It also > >> avoids exim from calling some "inappropriate" ioctls. > >> This seems to run fine on my server, but I would like a wider testing > >> and bug reporting if possible. > > > > I'll step in and say I am really sceptical this diff works in all usage > > cases, and if it does not work for all usage cases, then it is wrong > > because the program will terminate unexpectedly in those cases (and > > who knows, drop mail, leave lock files around, who knows) > > > > It is very rare for pledge to be added to an existing big program without > > making the program worse. If you really care for this, you need to > > establish > > a test-setup and invest some major time checking all the behaviours, while > > reading the source code with a cynical mindset. > > > > Even then: > > > > if (pledge("stdio rpath wpath cpath inet fattr id proc" > > " tty exec flock unix dns getpw", NULL) == -1) { > > > > What does it prevent the program from doing if it gets holed? Not much. > > That's close to not calling pledge at all. > > > > Yes, I know, it's a "better than nothing" solution. I tried to make it > run for all use cases, which is quite wide as you said.
Hang on -- it is not "better than nothing". It leaves the programs with enough abilities so that, if it got holed, it could still do everything it needs to do to own the system. pledge and unveil are used elsewhere to ensure privdrop/privsep designs, and here it is not doing that. But that pledge is talking away a vast number of smaller posix interfaces, which are unneccessary for holing the system. > In fact it already helped find a place where pledge was killing the > process for ioctl(3,SIOCGIFCONF,0x7f7ffffc3a28), and there is no > pledge call to authorize that. Hence the part of the patch which > prevents exim from using that call and use a cleaner getifaddrs() > instead. So I expect to catch more of those nasty things. That is well justified and should be seperate proposal. In this case because SIOCGIFCONF is often associated with poor ipv6 handling because the sockaddr isn't a powerof2 sized because the design team screwed up not putting a pad word in to align it.
