Setting the domain name fails with setdomainname setting errno=EPERM. Because connmand isn't given CAP_SYS_ADMIN by systemd. Which needs to be fixed in connman.service. I'd suggest just removing the capability bounding from the Systemd service because CAP_SYS_ADMIN and CAP_SYS_MODULE basically equal root anyway. Relevant line: https://git.kernel.org/pub/scm/network/connman/connman.git/tree/src/connm...

On Thu, 2017-08-24 at 20:32 +0200, Daniel Wagner wrote: > @Patrik: you have added the capabilities initially: > > 36aaa77f88d0 ("connman.service: Restrict capabilities") > > Any strong feelings, arguments against removing the > CapabilityBoundingSet? CapabilityBoundingSet is preferred in order to keep some kind of lid on ConnMan, although CAP_SYS_ADMIN is reaching quite far anyway. Its not nice to add CAP_SYS_ADMIN, but there doesn't seem to be any other way to do it either. And now that I look at it, don't we fork when writing a backtrace, which was restricted by a capability I can't remember...

On Fri, 2017-08-25 at 11:40 +0200, Daniel Wagner wrote: > """ > To summarize: CAP_SYS_ADMIN has become the new root. If the goal of > capabilities is to limit the power of privileged programs to be less > than root, then once we give a program CAP_SYS_ADMIN the game is more > or less over. That is the manifest problem revealed from the above > analysis. However, if we look further, there is evidence of an > additional problem, one that lies in the Linux development model. > """ Indeed... Do we need to set the domainname in the first place? Or hostname? Right now I don't remember which issues setting the domainname were supposed to solve. Setting the hostname probably fails as well(?), but keeping the same hostname makes me feel at home independent of network :-)

On Fri, 2017-08-25 at 12:50 +0200, Daniel Wagner wrote: > Patrik Flykt <patrik.flykt(a)linux.intel.com&gt; writes: > > > On Fri, 2017-08-25 at 11:40 +0200, Daniel Wagner wrote: > > > """ > > > To summarize: CAP_SYS_ADMIN has become the new root. If the goal > > > of > > > capabilities is to limit the power of privileged programs to be > > > less > > > than root, then once we give a program CAP_SYS_ADMIN the game is > > > more > > > or less over. That is the manifest problem revealed from the > > > above > > > analysis. However, if we look further, there is evidence of an > > > additional problem, one that lies in the Linux development model. > > > """ > > > > Indeed... Do we need to set the domainname in the first place? Or > > hostname? Right now I don't remember which issues setting the > > domainname were supposed to solve. Setting the hostname probably > > fails > > as well(?), but keeping the same hostname makes me feel at home > > independent of network :-) > > IIRC it was added to allow to configure embedded devices via DNS. I > know > the feeling of hostname changing. Luckely there is > AllowHostnameUpdates=false :) > > So do we agree on dropping the capabilities attempt? If you ask me I rather keep off the root privilegies and fail with the host and domain names. But people can depend on this feature, so... Keep the line, but comment it out in the service file? With perhaps an explanation attached on a line above?