NSS integration for TACACS+

[benschumacher]

Hello-

I've got a module that provides integration into GLIBC's NSS layer for TACACS+ based on the 'libtac' from this project. The module provides a mechanism for operators to rely solely on TACACS+ and PAM functionality to provide shell-level access to end users.

The code is working and is deployed as part of a project I was working on, and I've been working to get clearance to fully open source the code. I could spin up a separate GitHub project for it, but would be just as happy to make this additional functionality a part of this project.

Would that be interesting to to this community? It is currently maintained separately in our local VCS, but I could rework it to use the same build toolchain that is currently used by pam_tacplus, and send a pull request back to this project if that would be interesting.

I'd obviously be happy to provide more details about how it operates, as well.

Thanks, Ben

[daveolson53]

oferbochan notifications@github.com wrote:

Thank you,

could you please advise where i can download this packages ?

I'll have them on github in a couple of days, after I do more testing.

On 29 Jun 2016, at 9:39 AM, daveolson53 <notifications@github.com mailto:notifications@github.com> wrote:

audisp-tacplus_1.0.0-1_amd64.deb

Dave Olson olson@cumulusnetworks.com

[daveolson53]

oferbochan notifications@github.com wrote:

Thank you,

could you please advise where i can download this packages ?

For right now, I'm on hold again to push it up to github, while we do more testing.

For those who want the source, I can send you a tarball, just reply to be directly at the email address below, and I'll send you a 5MB tarball of the sources and instructions on building, installing, and configuring.

Dave Olson olson@cumulusnetworks.com

[oferbochan]

Thank you I will appreciate to have it.

Sent from Ninehttp://www.9folders.com/

---

From: daveolson53 notifications@github.com Sent: Jul 7, 2016 12:58 AM To: jeroennijhof/pam_tacplus Cc: Ofer Bochan; Comment Subject: Re: [jeroennijhof/pam_tacplus] NSS integration for TACACS+ (#28)

oferbochan notifications@github.com wrote:

Thank you,

could you please advise where i can download this packages ?

For right now, I'm on hold again to push it up to github, while we do more testing.

For those who want the source, I can send you a tarball, just reply to be directly at the email address below, and I'll send you a 5MB tarball of the sources and instructions on building, installing, and configuring.

Dave Olson olson@cumulusnetworks.com

You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-230919863, or mute the threadhttps://github.com/notifications/unsubscribe/ATIuNCzzqDmprw3Bn77koz8bGA6bUjseks5qTCT4gaJpZM4EULZJ.

[ganeshragnarayanan]

We have a similar requirement. For this I wrote a nss module to map all users that are not present locally to a fixed user. Please refer github below. I had one question, is there a way to get the UID, home directory, etc. from the tacacs server ?

https://github.com/ganeshragnarayanan/nss_tacacs/

[kravietz]

In theory yes - TACACS+ server can send attributes in the response but currently they are simply discarded by the library.

[daveolson53]

Dave Olson olson@cumulusnetworks.com wrote:

oferbochan notifications@github.com wrote:

Thank you,

could you please advise where i can download this packages ?

For right now, I'm on hold again to push it up to github, while we do more testing.

For those who want the source, I can send you a tarball, just reply to be directly at the email address below, and I'll send you a 5MB tarball of the sources and instructions on building, installing, and configuring.

Well, quite a bit later than I'd planned (or hoped), I've got everything up on github for review or for people to pull and play with.

I first started talking about this months ago, and I've sent tar balls to various people since then.

Most of the repos are new, although have derivative work in them.

libpam-tacplus is based on a somewhat old version of pam_tacplus. It starts from commit 748330bca92e7a653c53f4a8af47cb6eef4f2c40 on 29 June 2016. I'll catch up with changes since then at some point, but it may take a while, in part because I did some cleanups and refactoring along the way that conflict with later work.

I made changes to allow tacacs users to authenticate and login even if they have no local (or ldap) password entry. It uses the libtacplus-map library to map from local tacacs0..tacacs15 users for a password entry template, including uid and home directory.

One of the things that I did was to make it possible to have a single point where the tacacs servers and keys (and other variables are defined), that can be used by all the packages. That location is /etc/tacplus_servers (and should be mode 600 and owned by root if you care about the secret key remaining private). That simplifies end-user config significantly, I think.

The other repo that is not new is sudo. It's based on debian jessie sudo 1.8.10p3. It has a small patch to plugins/sudoers/parse.c to allow the mapped tacacs users to sudo, while having only the local (e.g., tacacs15) user in the sudoers file.

The other repos are tacplus-client (debian metapackage to simplify installs), libsimple-tacacct (simple interface for accounting to be used by other shared libraries), libnss-tacplus (NSS plugin), audisp-tacplus (auditd plugin with rules to enable accounting of commands run by users who login via libpam-tacplus).

The repos are all on github under https://github.com/daveolson53/

This code is shipping in Cumulus Linux 3.1 (I work for Cumulus Networks), although a few cleanups and bug fixes have been made since then (and are in the repos below), and those will ship with Cumulus Linux 3.2.

The Cumulus web doc for the tacacs client package is here; it may be helpful to some: https://docs.cumulusnetworks.com/pages/viewpage.action?pageId=5118449

I'd be interested in any and all comments, suggestions, problems spotted or encountered, etc. All of the repos have README files and some documentation, that I've tried to make accurate. If any of this email or those docs aren't clear, let me know about that as well.

To try to clean up build dependencies, some of these packages now build -dev packages to be installed as well in order that the other packages can be built.

You can see build interdependenies by looking at debian/control for each of the packages.

This all builds and works on debian jessie, and other distros are uncharted territory, although earlier versions were compiled by some people on recent fedora, centos, and ubuntu, with various issues.

It's been run against the linux tacplus server on several distros, and also against the Cisco ACI tacacs server. If any of you run against other servers, please let me know (successfully or otherwise).

An earlier version of this code compiled and worked on debian wheezy, and the current code problem still works, although I suspect some jessie-specific things have crept in.

I'm about to start working on command authentication, for the case where the tacacs client gets a restricted shell, and invokes commands that are all symlinks to the authentication command. After authentication, the "real" command will be exec'ed with it's arguments. It's a pretty narrow use case, but some people are interested.

Here are the repo URLs using https:

pam_tacplus: https://github.com/daveolson53/pam_tacplus.git

sudo: https://github.com/daveolson53/sudo.git

libtacplus-map: https://github.com/daveolson53/libtacplus-map.git

libsimple-tacacct: https://github.com/daveolson53/libsimple-tacacct.git

libnss-tacplus: https://github.com/daveolson53/libnss-tacplus.git

audisp-tacplus: https://github.com/daveolson53/audisp-tacplus.git

tacplus-client: https://github.com/daveolson53/tacplus-client.git

Thanks,

Dave Olson olson@cumulusnetworks.com

[azharfazil]

@daveolson53

Just to confirm for your nss library, if the priv level is only given by tacacs+ server after a successfull authentication. For each first ssh session, the user will always get the priv level 0. (default value from nss lib). Is it common to only get the priv-level (in authorization req) only after a successfull authentication??

I find it hard to convince the tacacs+ server administrator to return the priv level even before a successfull authentication.

Azhar

[daveolson53]

azharfazil notifications@github.com wrote:

@daveolson53

Just to confirm for your nss library, if the priv level is only given by tacacs+ server after a successfull authentication. For each first ssh session, the user will always get the priv level 0. (default value from nss lib). Is it common to only get the priv-level (in authorization req) only after a successfull authentication??

That's not the behavior that I see. libnss-tacplus gets the attributes, including the privilege level. If it didn't, it couldn't map to the correct local UID.

For the customers that I have using this, with various tacacs servers, I have not had any reports of this behavior.

I find it hard to convince the tacacs+ server administrator to return the priv level even before a successfull authentication.

I can certainly see that being a local choice, and even some justification (albeit minor) for that position.

If you are in that environment, then libnss will always map to priv level 0, as you say, if the user is not logged in. Once the user is logged in, it should work correctly because we keep the mapping locally.

It's possible (likely, from what you report) that occurs too late for the setuid from sshd.

I don't have an answer for that environment, and I'm not sure that one is possible.

Dave Olson olson@cumulusnetworks.com

[azharfazil]

@daveolson53 ,

That's not the behavior that I see. libnss-tacplus gets the attributes, including the privilege level. If it didn't, it couldn't map to the correct local UID.

So you are saying normally when ssh sent an Authorization request (through libnss) it should be getting the priv level in the response?

-Azhar-

[daveolson53]

azharfazil notifications@github.com wrote:

@daveolson53 ,

That's not the behavior that I see. libnss-tacplus gets the attributes,
including the privilege level. If it didn't, it couldn't map to the
correct local UID.

So you are saying normally when ssh sent an Authorization request (through libnss) it should be getting the priv level in the response?

Yes.

As you indicated in your earlier email, it is possible to configure a server to not respond with attributes. It just isn't commonly done.

So far (it's still relatively early in deployment experience), your case is the only one that I've heard of.

Dave Olson olson@cumulusnetworks.com

[pprindeville]

I concur with @azharfazil... leaking information to a someone who might not even be a legitimate user seems to be a security hole.

This is why the getty error message "Password incorrect" was changed to "Login incorrect"... so that you can't discover usernames by providing bad passwords.

Answering "Login incorrect" keeps you guessing about whether the username or the password is faulty.

[daveolson53]

Philip Prindeville notifications@github.com wrote:

I concur with @azharfazil... leaking information to a someone who might not even be a legitimate user seems to be a security hole.

Remember that they do at least have the shared secret between the client and the host, so it's not a wide open leaking of info.

And after all, most unix/linux systems let you get the "privilege level" (the UID) from /etc/passwd completely unprivileged.

Still, I agree it's a choice some sites will make.

For those sites, my client package will not work very well, everybody gets mapped to the lowest privilege level.

And for NSS, I can't think of anything that would work well under these conditions, short of mapping to the lowest level.

Dave Olson olson@cumulusnetworks.com

[daveolson53]

hari-at-git notifications@github.com wrote:

Hi Daveolson,

Is it possible for you to send me the debian packages for the corresponding pam libs

Thanks in advance!

I can send them to you if you are on Debian Jessie 64bit x86_64. I'm not set up to build them for other distros or processors.

Reply directly to me: Dave Olson olson@cumulusnetworks.com

Dave Olson olson@cumulusnetworks.com

[wowczarek]

Wow, this is perhaps the longest comment thread on GitHub I've ever seen.

Really keen to see the outcome from this work, but looks like in the end, it is a fundamental problem: TACACS is an AAA system, not a name service. For "other network OSes" using their own CLIs, this is fine.

Anyhow, I had the same problem (authenticating Linux jump boxes), and I fixed it with this:

https://github.com/donapieppo/libnss-ato

It maps a default uid/gid to unknown users (local account must exist), which works in the sense that you authenticate with TACACS, and for a shell session you land in a common home directory. Not ideal for shell access if you want separate accounts, but better than nothing - and in fact, many of those "other OS", do exactly this - map a common user. I think this is acceptable for a network device.

Lack of out of the box TACACS and RADIUS authentication is a bit embarrassing for Cumulus - this solution would be better than nothing. Downside: any random username locally resolves to your "remote" user.

[joakim-tjernlund]

Any idea if ATO would work in combination with creating a user later in TACACS pam module? ATO would be used to just get past the initial step in openssh and then have TACACS to actually create a real user as part of the login process

[daveolson53]

Wojciech Owczarek notifications@github.com wrote:

Wow, this is perhaps the longest comment thread on GitHub I've ever seen.

And I still haven't done part of what I promised. Oh well. Works gets in the way...

Really keen to see the outcome from this work, but looks like in the end, it is a fundamental problem: TACACS is an AAA system, not a name service. For "other network OSes" using their own CLIs, this is fine.

Yep.

Anyhow, I had the same problem (authenticating Linux jump boxes), and I fixed it with this:

https://github.com/donapieppo/libnss-ato

It maps a default uid/gid to unknown users (local account must exist), which works in the sense that you authenticate with TACACS, and for a shell session you land in a common home directory. Not ideal for shell access if you want separate accounts, but better than nothing - and in fact, many of those "other OS", do exactly this - map a common user. I think this is acceptable for a network device.

That's basicly what I did with RADIUS, where authorization and authentication are a single operation, so it's pretty hopeless to do anything better.

I use an actual user name in the config file, and look it up in /etc/passwd (only locally, not nss, for obvious reasons).

No git repo, but debian source tarball is available. It's here (the dsc file is in the same place): http://repo3.cumulusnetworks.com/repo/pool/cumulus/libn/libnss-mapuser/libnss-mapuser_1.0.0-cl3u1.tar.gz

Lack of out of the box TACACS and RADIUS authentication is a bit embarrassing for Cumulus - this solution would be better than nothing. Downside: any random username locally resolves to your "remote" user.

Dave Olson olson@cumulusnetworks.com

[wowczarek]

All right - my idea is this:

1. pam_tacplus and pam_radius get extra options: user_file (say /etc/tacplus_passwd), start_uid, default_guid, default_shell, home_dir. If user_file is not set, this extra functionality is disabled.
2. any time authentication is successful, but getpwnam() fails, pam_tacplus and pam_radius adds an entry to user_file with the name, next free uid (starting with start_uid), default shell, and home dir set to home_dir/username
3. a simple libnss_extra is developed which works on user_file.
4. livedhappilyeverafter

[daveolson53]

Wojciech Owczarek notifications@github.com wrote:

All right - my idea is this:

1. pam_tacplus gets extra options: user_file (say /etc/tacplus_passwd), start_uid, default_guid, default_shell, home_dir. If user_file is not set, this extra functionality is disabled.
2. any time authentication is successful, pam_tacplus looks up the user by name, and if the user does not exist, it adds an entry to user_file with the name, next free uid (starting with start_uid), default shell, and home dir set to home_dir/username
3. a simple libnss_extra is developed which works on user_file.
4. livedhappilyeverafter

This is fairly close to what I implemented in https://github.com/daveolson53/pam_tacplus.git and the related repos https://github.com/daveolson53/libnss-tacplus.git for nss and https://github.com/daveolson53/libtacplus-map.git for the mapping db

But rather than making everything configurable, I just create template accounts in /etc/passwd and /etc/group when the package is installed, and use those templates, replacing the template account name and (optionally) homedir with the name of the account logging in.

There are also other repos to handle per-command accounting via an audisp plugin, etc., under https://github.com/daveolson53/

There are man pages, config files, etc. An overall user doc as this code is implemented on Cumulus Linux is here: https://docs.cumulusnetworks.com/display/DOCS/TACACS+Plus

The upstream repos are a bit out of date, I probably won't get them updated for a few weeks unless there is really strong interest.

Dave Olson olson@cumulusnetworks.com

[wowczarek]

Hi Dave,

Two similar, but different use cases. One is "being able to log into a network device", where a template user is OK, and the other (mine) is for general multi-access systems e.g. jump boxes that need to be plugged into existing tacacs or radius - where you want "proper" users with different uids. Anyhow, aaa != ns. Will have a look at your repos, thanks.

[wowczarek]

...one silly Idea I had for UIDs was to use some hash with a repeatable algorithm on top that gets it above a certain value... FNV or something.

[daveolson53]

Wojciech Owczarek notifications@github.com wrote:

Hi Dave,

Two similar, but different use cases. One is "being able to log into a network device", where a template user is OK, and the other (mine) is for general multi-access systems e.g. jump boxes that need to be plugged into existing tacacs or radius - where you want "proper" users with different uids. Anyhow, aaa != ns. Will have a look at your repos, thanks.

I agree AAA isn't part of NSS per se, but NSS is certainly part of the linux implementation of AAA.

You can't just use a staticly maintained start_uid though, if that's your use case, because other things may create user accounts. You'll have to step through uid's until you find one that's available.

Given that, you may as well just maintain a minimum uid, and call adduser or useradd to do the rest for you, rather than trying to keep a separate list of users and uids

Dave Olson olson@cumulusnetworks.com