Issue #1400: username - principal name mapping of GSSAPI authentication - koji

koji

#1400 username - principal name mapping of GSSAPI authentication

Closed: Fixed 4 years ago by tkopecek. Opened 5 years ago by julian8628.

We now treat env REMOVE_USER as username vai GSSAPI auth, and it's from principal's service part.
for example:
- djoe of djoe@EXAMPLE.COM
- bdavid of bdavid@EXAMPLE.COM
- service/hostname of service/hostname@EXAMPLE.COM

But we could also create a user with a specified principal whose service part is not exactly it's username for old kerberos way.
for example:
- bdavid of djoe@EXAMPLE.COM
- shortname of service/hostname@EXAMPLE.COM

Then via GSSAPI. bdavid@EXAMPLE.COM will be authenticated as djoe, and authentication as service/hostname@EXAMPLE.COM won't get the real username - shortname.

IMO, that would be a potential security issue.

mikem commented 4 years ago

I'm not sure where the security issue is.
Creating users requires admin privileges, and creating arbitrary krb credentials is presumably a privileged action within whatever kerberos infra the Koji instance is using.

I can see how an admin mistake in user creation could cause a problem, but that is the nature of admin access. The ability of root to run rm -rf / doesn't constitute a security bug.,

Maybe I'm missing something?

julian8628 commented 4 years ago

I assume that, if the admins of kerberos infra don't take the change of administration of koji, they wouldn't know if the principal is used by more than one koji user. Because for GSSAPI, auth is based on username, and for krbV it's based on krb_principal.
The benefit of changing GSSAPI auth to check krb_principal is reducing such kind of administration mistake.

But, it's not strictly a security bug.

Metadata Update from @julian8628:
- Issue private status set to: False (was: True)

4 years ago

julian8628 commented 4 years ago

PR #1419