3

Currently I'm building an authentication system using Linux PAM for a python daemon process. It will need to authenticate remote users from a variety of front-ends against the local user list. (Amongst other options but those I do not have trouble with) It will be used as a centralised management and configuration system.

However because it is slightly insane from a security point of view to run the daemon as root I have been looking at alternatives.

The options I came across were:

  • Creating a group with read access to the /etc/shadow file and adding the daemon user to the group. (Additional downside, will need write access too if it needs to update user credentials. Which may come back to the initial root issue.)
  • Invoking a shell from the daemon and use su to temporarily switch to root/given user before authenticating. (One example included doing su [username] which would mean you are authenticated if the call succeeds.)
  • Creating a separate process that does only authentication under root and is communicated with through UNIX domain sockets. (This currently has my preference as the other two feel more like hacky workarounds.)

I have the nagging feeling I am missing an obvious solution but I have no idea what that would be. If this is not the case which one would be preferable from a security standpoint. What I found had was split between the various options without much insight into the trade-offs or how it compares to the other options. Because of the nature of the applications it will manage security is the highest priority in regards to any solutions.

||improve this question
  • 1
    Have you seen this: stackoverflow.com/questions/5286321/… . IMHO PAM doesn't really lend itself to this, have you considered and eliminated LDAP? – mr.spuratic Mar 14 '13 at 11:33
  • @mr.spuratic I have considered the same question and the module in question. It still needs root privileges which is why it offers the same solution as the last of my options. Use a separate escalated process. In regards to LDAP, this is one of the alternative authentication options. However those are relatively easy to implement. Through PAM or otherwise. However not all deployment locations for the software will have access to an LDAP/Kerberos infrastructure. – Zimrilim Mar 14 '13 at 12:16
2

As you ouline, due to the limitaiton of /etc/shadow access, at some level, your application will either have to access that file or access some other module/service which has access to that file. There is no avoiding it if you want a solution which uses locally managed user credentials (unless you totally roll your own, which I strongly recommend avoiding).

I think your best approach is to separate the authentication component. Apart from having the benefit of limiting your exposure surface, it has another great advantage not yet mentioned. From your post, it seems this software will run at client sites, some of which may have LDAP, some of which will not. If your authentication component is modularised/separate from the core of your application, you have the possibility of getting the best of both worlds. Basically, your client site can use the method which fits best with their architecture.

Keeping the environment as straight-forward and consistent as possible is almost as important as using the right technology. Many security problems arise because the environment or architecture is too complicated. Changes get made by someone who doesn't fully understand the full implications and the next thing you know, you have a major security hole.

If you write your application in such a way that it can pass off authentication to an external module, you can allow sites to select what fits best for them. They avoid having to manage yet another identity source, can ensure consistency across their envrionment and possibly get additional benefits, such as single sign-on or same sign-on etc. You could provide a 'default' auth module which uses PAM for those sites that don't have LDAP or similar.

The challenge with this approach is in selection or definition of the interface. How should the communication occur? I would keep it simple. Possibly domain sockets, but perhaps other standards, such as SAML 2.0 may be worth checking out.

You may also be intersted in this article, which talks about using PAM to control service access

https://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/699697-how-the-linux-foundation-and-fedora-are-addressing-workstation-security

Also, depending on the deployment platform - redhat or debian based, you should check out SELinux and AppArmor for ways to limit potential problems, such as restricting what resoruces an executable is allowed to access etc.

||improve this answer
  • Of course LDAP is my preferred course of action in the eventual Auth module. Right now I have started implementation on a system that uses domain sockets for the communication. And does make accessing it a bit more unified across the entire system. Which is more than the management application. I am not sure yet if I should do the LDAP and perhaps eventually Kerberos authentication through this external module as well. But will update on that once I have had some more time to weigh the pros and cons there. – Zimrilim Mar 28 '13 at 8:57
0

Another possibility would be to run (part of) your program as root inside a virtual environment. Linux containers (lxc) make this lightweight.

Consider that anything your application can do, an attacker can do if your application is compromised. Therefore you should not allow (the bulk of) your application to expose valid user names or make password checks at an unlimited rate, let alone change passwords. So privilege separation in some form is the way to go.

My preference goes for LDAP because it is a well-known, widely-supported protocol and intrinsically separates the user database from the application. You can let the LDAP server worry about keeping the passwords safe and doing verifications correctly, but also about things like rate limiting, though your application may participate in rate limiting if it has additional knowledge about the provenance of authentication attempts. LDAP is also more likely to be adaptable to federated authentication, should you want to add this feature.

That your deployments may not have LDAP available is not an obstacle. Include an open-source LDAP server of your choice and run it on a custom port and listening only on localhost.

||improve this answer
  • I agree that privilege separation is important. But what advantage does using LDAP have over implementing a separate PAM module that introduces far less dependencies than installing a whole new program with more functionality than is needed. That additionally needs to be kept up to date separately. One could argue that this would increase the attack surface to a larger extent. – Zimrilim Mar 28 '13 at 9:02
  • @Zimrilim An independently-maintained PAM module has the advantage that you benefit from upstream's security updates and mature design. You have to balance that against the smaller attack surface of an ad hoc, in-house component. – Gilles 'SO- stop being evil' Mar 28 '13 at 19:43
0

Although an answer has been accepted here, I don't think it's a very good one.

Creating a group with read access to the /etc/shadow...

No. A long time ago, someone had the wonderful idea that the OS should authenticate users, not programs - even where the user does not already have a session, and came up with the idea of PAM. With PAM the mechanism by which authentication occurs is not the concern of the application seeking to authenticate the user.

slightly insane from a security point of view to run the daemon as root

Running does however massively simplify the process of authenticating and of changing to the authenticated uid. If the latter is not an requirement then you might consider invoking the authentication step via sudo / a setuid script (there used to be a very simple example included with squid) or even as a secondary daemon.

There's lots of ways to test a user and password - using su (or ssh) has the complication that you need to implement bi-directional communication with a new process - in much the same way as 'expect' does. It might be a lot simpler to test the username/password against a POP mailbox if you're adverse to implementing the authentication yourself.

There may be a way of changing uid when you're not root - but that's probably a new question.

||improve this answer
  • Downvoted with no explanation? – symcbean Dec 23 '13 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.