mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5751] ssh-agent: eval hangs without --deterministic-shutdown #3082
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3082
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Mar 25, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5751
I've had
deterministic-shutdownin myssh-agent.localever since the option was introduced. Never realised until accidentally bumping into this today that the current ssh-agent.profile is likely broken for most users.The bad...
The good...
@rusty-snake commented on GitHub (Mar 25, 2023):
This sounds like it reports the pid inside firejail and not the pid of the initial pid-namespace.
@rusty-snake commented on GitHub (Mar 25, 2023):
This works because it kills the ssh-agent daemon process I guess.
@ghost commented on GitHub (Mar 25, 2023):
Good observation. I'll do more testing and compare what SSH_AGENT_PID and SSH_AUTH_SOCK contain with/without firejail.
@ghost commented on GitHub (Mar 30, 2023):
UPDATE
Even when the 'hanging issue' can be fixed via
--deterministic-shutdown, firejailing ssh-agent always results in the running agent being unreachable. Likely this is due to firejail's use of pid namespaces and AFAIK cannot be avoided. Hencewe should NEVER sandbox ssh-agent.I'm closing #5752 and #5753 as both PR's have lost their relevancy in this context IMO.
FWIW we don't need to do anything for
firecfg, as #1568 already keeps it out. BUT we do need to considerdropping ssh-agent.profile, something that rarely happens and should be made clear somehow. Adding a note in RELNOTES might be the best we can do here.@kmk3 commented on GitHub (Mar 30, 2023):
@glitsj16 on Mar 30:
Does this affect only the
ssh-agent $commandcase or the general case ofrunning
ssh-agent+ssh-add+ some program? Could you post an example?Wouldn't both sides having access to the socket be enough regardless of any
other namespaces?
If the only problem is the PID namespace, wouldn't it be enough to use
--joinfor the applications that should access the given ssh-agent instance?
This might even be a good way to have multiple ssh-agent instances running with
different keys being used for different programs.
Examples of theoretically isolated groups (using
PID:program-name):Good to know.
Yes; that was done for nvm.profile. If ssh-agent.profile is to be dropped, I
think just adding it to the RELNOTES would be fine, especially considering that
it's already been disabled in firecfg.config for a while.
@ghost commented on GitHub (Mar 30, 2023):
It's the general case that's broken:
This works:
Although I can understand your reasoning, how could one
--jointhe ssh-agent sandbox if that requires --deterministic-shutdown? That's a use case I can't get working here, but I'm always open to suggestions.Luckily there are several other SSH agents that do work when firejailed.
@kmk3 commented on GitHub (Apr 5, 2023):
@glitsj16 on Mar 30:
Ah I see what the problem is now.
--deterministic-shutdownmakes ssh-agent be gone right after running it.There is nothing running as
$SSH_AGENT_PIDand no file at$SSH_AUTH_SOCK,so ssh-add can't do anything:
As for hanging when trying to daemonize, it seems to be due to the following
issue:
As a workaround, it looks like it's possible to have the shell put
ssh-agentin the background and redirect its (initial) output in order to read it:
It seems to work regardless of
--deterministic-shutdown.Note also that ssh-agent can also be told not to daemonize:
From ssh-agent(1):
Which also works:
Not sure whether it would be better to use
-Dor not. Same for--deterministic-shutdown.Good to know.
@ghost commented on GitHub (Apr 6, 2023):
@kmk3 Thanks for researching and the workarounds. After further experimentation I settled on a ssh-agent systemd user service hardened via firejail. For me that's the most convenient way, as I had some trouble to implement your workarounds via shell scripting. In both cases I had to run the
. outputstep manually from CLI for them to work. If you ever find a way to do that from a wrapper script, I would be interested to learn.Until there's a fix for #3491 it seems there's nothing much to do here for the ssh-agent profile.
@kmk3 commented on GitHub (Apr 6, 2023):
@glitsj16 on Apr 6:
No problem.
Here's an attempt (it's not very pretty, but it works):
myssh-agent (simplified version):
myssh-agent (with error handling):
Run it as:
@ghost commented on GitHub (Apr 6, 2023):
Thanks for the shell scripts. Very nice!