Can/Should(?) single user be able to see the logs of connections / impersonation

[Carreau]

We receive a request on the security mailing list from a JupyterHub user (not admin) to see the logs of his own connections and if there was impersonation from an admin.

Is that something that is doable ? Is that something that could be done ?
My understanding is that detecting impersonation at single server level is not possible.
Could it be with hub sending an ignored in other case "impersonation:True" header ?

Should single user server store a UI accessible logs of connection date/time ?

User also requested IP but I guess that is not available to single user servers.

[minrk]

Detecting impersonation isn't really feasible. If you have credentials, you have them, and you are identified by the credentials with which you make a request. Each request is logged with who made it, though, including ip addresses. A malicious admin does definitely have the ability to craft a session where they are indistinguishable from the user.

What we can do is write server logs to a user-readable file. We do this in a repo2docker entrypoint, so any mybinder.org user can tail -f .jupyter-server-log.txt, but could probably do it directly in jupyter-server as well (using the same FD-level output-splitting feature we have in ipykernel), so all deployments would be able to use it.

[manics]

What threats does the user want to defend against? It's a nice-to-have feature from the perspective of openness and transparency to JupyterHub users, but from a security auditing point of view I think it's use is limited to deployments where all of these apply:

• JupyterHub admins don't have access to the underlying infrastructure (otherwise they could access the storage directly, or shell in, etc)
• JupyterHub admins don't have permission to deploy or configure JupyterHub (otherwise they could override any logging)
• JupyterHub admins require remote access to user servers (RBAC allows you to give "admins" permission to do everything except access user servers)

[Carreau]

I guess it can be useful to list the access times to not have to escalate to admins, or even to know if you credential are compromised. If from the UI you can view that there was access at times you do not recognize, then you can escalate. A few platform (gmail), have a list of last connections and activity with IPs.

But I agree it's of limited use.

[minrk]

JupyterHub does have a last_activity field in the database, but it only tracks the last time each credential is used, anywhere in JupyterHub. We could have a separate last_activity tracker for more specific combinations, e.g. the last time a (user, ip, component) was used. But that gets into some sensitive user tracking that I'd generally like to avoid (especially by default), but it can be relevant for user purposes.

So far, we've only been concerned with security logging from the perspective of admins, but that doesn't help users who are suspicious of their peer (or admin) users. That's a challenging problem, and something we should probably think about what's in scope for us to provide.

I think sending audit events to a logger is probably the solution we should have for this. If we want users to be able to access this info for their own servers, we could set up a local event-log endpoint (and potentially viewer).