1.3.6 for now (needs further discussion)

Are you sure it is only capability which is required?

I check selinux-policy and it says:

sh$ grep cap dirsrv*
dirsrv-admin.te:allow dirsrvadmin_t self:capability { dac_read_search dac_override sys_tty_config sys_resource };
dirsrv-admin.te:        allow dirsrvadmin_script_t self:capability { fowner fsetid setuid net_bind_service setgid chown sys_nice kill dac_read_search dac_override };
dirsrv.te:allow dirsrv_t self:capability { sys_nice setuid setgid fsetid chown dac_override fowner };
dirsrv.te:allow dirsrv_snmp_t self:capability { dac_override dac_read_search };

But I do not know code very well.

Anyway +1 for capabilities

Well, I'm not making capabilities the default method of running DS quite yet: Let's start small. I had this working and searches working. I think the extra bits in selinux policy are selinux specific.

As well, some of those look like they aren't needed. We don't need sys_nice and dac_override. Those are pretty dangerous IMO. I think they are needed only when running as root to change ownership of things back to dirsrv. If we do this right, we won't need them.

So lets go with this, and test it carefully for 1.3.7/1.4.0. I want to get this in there because it allows containers to work, but systemd and rpm still use root and priv dropping.

ack

commit 92864e0
To ssh://git@pagure.io/389-ds-base.git
79307f5..92864e0 master -> master

What is the current status of this feature? The above comments indicate that it's not used in RPM packages, which matches what I see.

I wonder if ns-slapd has any protection to prevent arbitrary local user to start their own instance and bind port 389 before system service does so.

@thoger It has been added to the upstream RPM's but it may not be in the RHEL/Fedora ones. @mreynolds perhaps this was missed in a spec file sync? Look for https://pagure.io/389-ds-base/blob/master/f/rpm/389-ds-base.spec.in#_640

@thoger The security of a linux system is weak at best, but really comes down not to protection of the socket, but protection of the userid and their ability to read the config/db. If a user "x" tried to start ns-slapd it would fail due to no permissions on dirsrv owned files/folders.

Really, the only isolation is machine isolation, so untrusted users should never be allowed on your ns-slapd servers where they could effect a local root priv escalation anyway. Only vetted, trusted admins should be able to access these machines due to their high security and impact requirements.

Hope that helps,

The change is in Fedora, it was added via:

https://src.fedoraproject.org/cgit/rpms/389-ds-base.git/commit/?id=ca673ecc

I was trying to say that while it is there, it is not actually needed or used in any way.

Also my concern is not with a local user starting ns-slapd instance under their id. I assume that ns-slapd allows you to specify where to look for configuration and data files. So the permission on the system config/db files is not that important as attacker would likely want to start their instance with their own config/db. If they can grab port 389, they may, for example, give them access to other systems using the LDAP server to store user authentication or authorization data.

I agree that giving untrusted users access to high value production LDAP servers is a risk/problem of its own, I also think these privileges are also a risk. And as noted above, those extra privileges are not actually used/needed at the moment, so does not look like a justified risk.

It's not used now, but it is used in containers because they do not have root available. We were working toward root-less start up of the ns-slapd binary with systemd/init as well.

I do not believe that this is a real security issue however because the protection of the socket is provided through protecting access to the machine. Today, the state of Linux OS security is very poor - any access to a machine is equivalent to having root access anyway. Thus the only security is in isolation of the machine so having dirsrv with capability is a non issue, and helps us to continue to work toward not needing root permissions and id swapping in the future.

Thanks for your concerns on this matter, and the timely reminder that I should finish the "root-less" dirsrv start up process for systemd.

I can't agree that any access is equivalent to the root access. There are issues found that allow privilege escalation, but those are considered security problems and addressed as such. That's not to say that separating critical services to dedicated machines, VMs, or containers is a bad idea - quite the opposite, that is a recommended practice.

With your view that unprivileged access is equal to root access, what is the motivation for having root-less startup / container?

Few other quick ideas:

• Would it make sense to restrict this the capability use to container use case, without using that in packages and hence creating risk in cases where users install 389-ds on multi user or multi service system? I.e. have RPM packages install ns-slapd without capabilities and only have container creation recipe add capabilities?

• Restrict ns-slapd access to the dirsrv user/group.

There are two use cases for capability.

• Prevent requiring root on startup on systemd machines (capabilities)
• Allow dyanamic UID functions to work on containers (also needing capabilities)

Given that today we required root to start and then drop privileges, we are more at risk there. I don't think it's worth micro-optimising granularity of permissions where if someone is on your machine and can take over port 389 without you know, you have bigger issues.

ns-slapd can't be restricted to "just" dirsrv because someone may be using it in an odd way where they use a different userid for the process. Sadly we have to account for those cases even though I would love to say "it's dirsrv user/group only".

While I appreciate your concern about the security of the daemon - and would love you to continue to contribute concerns and discussions about this in the future - I think in this case you have to ask your self about the threat model you have. The threats to 389 often are not "ohh some rogue user is on the same machine" it's "weak acis", "network parsing" or "invalid state handling in entries". The list goes on. Mainly, these are all remote threats, and that's the attack vector we would see. 20 years ago on a mainframe where every user was logged into the same machine at once, yeah, this probably was a risk. But today, most services have a 1:1 mapping of service: os instance. So your ldap is on a server machine to dns, seperate to databases etc. As a result OS isolation is your security barrier at that point. Given all the hypervisor escapes/cpu issues/linux priv escalations/selinux being impossible to use, the real isolation, is OS and machine isolation.

I think if you want to continue this discussion, we could move to the 389-users list, and perhaps it could be worth writing something on our website of "our threat model" to help explain it.

https://bugzilla.suse.com/show_bug.cgi?id=1111564
There is a patch here for improving this feature

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1761

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.