Bug 1111564

Summary:	AUDIT-0: 389-ds: now uses fscaps.
Product:	[Novell Products] SUSE Security Incidents	Reporter:	Marcus Rückert <mrueckert>
Component:	Audits	Assignee:	Matthias Gerstner <matthias.gerstner>
Status:	RESOLVED FIXED	QA Contact:	Security Team bot <security-team>
Severity:	Normal
Priority:	P5 - None	CC:	astieger, jsegitz, matthias.gerstner, william.brown
Version:	unspecified
Target Milestone:	unspecified
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	patch that implements a capability drop

Description Marcus Rückert 2018-10-11 18:45:01 UTC

package: security:idm/389-ds

see also the discussion here: https://pagure.io/389-ds-base/issue/48432

in doubt we could go for root:dirsrv u=rwX,g=rX,o= with fscaps for netbind

Comment 2 Matthias Gerstner 2018-10-23 14:35:42 UTC

Thank you for opening the bug. We have currently a rather high load of
security reviews, therefore it will take a bit longer for us to take care of
this.

Comment 3 Matthias Gerstner 2018-10-29 17:43:02 UTC

Since this is only about CAP_NET_BIND_SERVICE I think there's no big review
required here. The ns-slapd opens the privileged port early on, the port
number is read from the configuration files. When only the 389-ds unprivileged
user or group can start the binary carrying the capability then all should be
fine.

I am not so sure how well tested this feature is. The upstream discussion
shows that not many people seem to have used this in two years. From the code
I don't quite understand how it is supposed to work. The code still assumes it
is started as root and performs a privilege drop to the unprivileged user
after binding sockets. If this privilege drop does not work then the execution
is stopped. "Dropping" privileges to oneself probably still works out. But
this means that it is required that the configured user and the user actually
running the daemon match, regardless of the availability of the capability bit
in the file system.

I think I can submit a whitelisting for this tomorrow.

Comment 4 Matthias Gerstner 2018-10-30 11:49:54 UTC

Created attachment 787723 [details]
patch that implements a capability drop

Comment 5 Matthias Gerstner 2018-10-30 11:52:53 UTC

One aspect that is somewhat missing is that the CAP_NET_BIND_SERVICE
capability is never dropped in the code, because the code is not capability
aware. Once the package works correctly with the new capability you can try
the patch in attachment 787723 [details] which should drop the capability instead of
trying to drop root privileges. If it works out we can try to bring it
upstream.

In the upstream discussion they stated, however, that this is not exactly a
security feature but a compatibility feature for containers. So maybe they
don't want the patch.

Comment 6 Matthias Gerstner 2018-10-30 12:21:46 UTC

whitelisting is on its way via OBS sr#645523

Comment 7 William Brown 2018-10-30 23:00:11 UTC

Hi there,

We would like the patch for dropping caps after they are used. do you mind if I copy it to the upstream source? 

Thanks,

William

Comment 8 Matthias Gerstner 2018-10-31 08:25:56 UTC

Hello William,

(In reply to william@blackhats.net.au from comment #7)
> We would like the patch for dropping caps after they are used. do you mind
> if I copy it to the upstream source? 

you are welcome to use it. That said: it is only a draft yet. It compiles but
I didn't have a chance to test it. It might need some work on the autotools
adjustments.

Comment 9 Matthias Gerstner 2018-11-26 13:07:09 UTC

The whitelisting should be in Factory by now. Closing as fixed.

Comment 10 Swamp Workflow Management 2018-12-20 11:10:06 UTC

This is an autogenerated message for OBS integration:
This bug (1111564) was mentioned in
https://build.opensuse.org/request/show/660250 Factory / 389-ds