pld rpm 5.4.17

[Jeffrey Johnson]

> On Jan 12, 2017, at 4:23 PM, Tomasz Pala <gotar at polanet.pl> wrote:
> 
> On Thu, Jan 12, 2017 at 14:58:51 -0500, Jeffrey Johnson wrote:
> 
>> AFAIK there???s only a handful of files that benefit from capabilities (but I haven???t looked recently: for all I know
> 

Hmmm … that seems to be about the same state of affairs when I last looked at capabilities.

> For the start - almost every SUID binary. Then - binaries that are

Ok, so linux wishes capabilites rather than setuid.

IMHO a better implementation (rather than adding spec file syntax and RPMTAG_* to packages),
might be to test RPMTAG_FILEMODES for the setuid (and setgid) and add
a capability dynamically instead of setuid/setgid.

Some benefits of above (JMHO) are
    1) switching to capabilities becomes a per-system, not a per-package, policy. If implemented
	correctly, a popt alias for rpm could be added to switch between capabilities <-> setuid/setgid
	even for already installed packages dynamically.
    2)	no bloat in package tag content, no “legacy compatibility” issues with rpmlib() tracking etc.
The costs are
    1) insufficiently general (but handles “almost every SUID/SGID case instantly)
     2) invisible implicit behavior invisible in tag content and depsolver metadata.

> currently run with EUID==root only to provide CAP_NET_BIND_SERVICE.

Last I checked, CAP_NET_BIND_SERVICE protected raw sockets in ping* and a handful
of other programs.

> While Linux capabilities are often referred as 'broken' (many of the
> cases are covered only by CAP_SYS_ADMIN), the counterpart you've
> mentioned, xattrs, are much more widely usable.
> 

Hmmm … (I.ve not looked) CAP_SYS_ADMIN is a way to control access
to a class of programs that users should NOT be executing (and I’d agree
that batter’s are a far better implementation: but RPM cannot dictate implementations,
and would need to support all of capabilities/xattrs/acls/… equally well, broken or not.

> Some of the caps security (i.e. dropping unneeded ones) can be handled
> by systemd units, but since they are in general upstream-provided, we
> shouldn't mess with them here. This won't help for overrided units
> anyway.
> 

This affects RPM only because of scriptets being run by the installer. E.g.
one might expect RPM to drop privileges after forking before running scriptlets
or adding CAP_SYS_ADMIN to run programs in the script let that would normally
not need to be run by a user. Yes, inheritance across fork already takes care
of most of the issues, but I’m sure there are some who would like to limit what
RPM can do while running scriptlets.

>> FWIW: handling capabilities (and acls/xattrs) within %post/%preun/%verifyscript scriptlets isn???t
>> all *THAT* ugly. JMHO, YMMV.
> 
> It doesn't need to be *THAT* ugly; it is 'so' ugly, that nobody uses them in such way.
> 

The SUID/SGID <-> capabilities is entirely invisible: UGLY is in the eye of the beholder,
and usually what you cannot see won’t bother you ;-)

JMHO, YMMV, etc etc

73 de Jeff