github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1726] [Info] What is the point of jailing ssh? #1165

New issue

Closed

opened 2026-05-05 07:34:36 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 07:34:36 -06:00

Owner

Originally created by @chiraag-nataraj on GitHub (Jan 11, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1726

So with ssh, jailing it doesn't seem to restrict the shell once you enter (I presume this is because that is spawned by sshd, not ssh?). So what is the point of jailing ssh at all?

Originally created by @chiraag-nataraj on GitHub (Jan 11, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1726 So with `ssh`, jailing it doesn't seem to restrict the shell once you enter (I presume this is because that is spawned by `sshd`, not `ssh`?). So what is the point of jailing `ssh` at all?

gitea-mirror

2026-05-05 07:34:36 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 07:34:40 -06:00

Author

Owner

@andrew-stclair commented on GitHub (Jan 13, 2018):

the point of sand boxing software is that if an exploit is found in it, it can be contained easier, or if you do not know/trust the software, you can test it and see what it will do.

a good example of this is comparing mobile operating systems to desktop operating systems like windows. windows gets tons of viruses but mobile phones do not get as much, because of sand boxing

in the case of ssh, it is just to be sure that if an exploit in the client software is discovered, it will not be as destructive if at all depending on what firejail is configured to let it do

@andrew-stclair commented on GitHub (Jan 13, 2018): the point of sand boxing software is that if an exploit is found in it, it can be contained easier, or if you do not know/trust the software, you can test it and see what it will do. a good example of this is comparing mobile operating systems to desktop operating systems like windows. windows gets tons of viruses but mobile phones do not get as much, because of sand boxing in the case of ssh, it is just to be sure that if an exploit in the client software is discovered, it will not be as destructive if at all depending on what firejail is configured to let it do

gitea-mirror commented

2026-05-05 07:34:42 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jan 13, 2018):

I understand why we jail programs. I jail pretty much all of the programs I use on a daily basis with restrictive whitelist-based profiles.

My question is: what threat model are we protecting against by jailing ssh? I understand jailing sshd, since that limits the amount of damage you can do over an SSH connection (and prevents someone who hijacks that session from having access to everything). But what is a scenario in which the biggest problem is that ssh has access to your files, or root, or whatever? Because if ssh is compromised, they can then get into your current session, which means they now can do whatever you can do in a normal SSH session. That is, they don't need root or access to your files through the ssh program if they can hijack your session.

@chiraag-nataraj commented on GitHub (Jan 13, 2018): I understand why we jail programs. I jail pretty much all of the programs I use on a daily basis with restrictive whitelist-based profiles. My question is: what threat model are we protecting against by jailing `ssh`? I understand jailing `sshd`, since that limits the amount of damage you can do over an SSH connection (and prevents someone who hijacks that session from having access to everything). But what is a scenario in which the biggest problem is that `ssh` has access to your files, or root, or whatever? Because if `ssh` is compromised, they can then get into your current session, which means they now can do whatever you can do _in a normal SSH session_. That is, they don't need root or access to your files through the `ssh` program if they can hijack your session.

gitea-mirror commented

2026-05-05 07:34:44 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 13, 2018):

I would say ssh client is one of the most secure programs out there. We sandbox it because we want to sandbox most programs. If you run into problems, delete the symlink from /usr/local/bin, I don't think is going to make any difference.

@netblue30 commented on GitHub (Jan 13, 2018): I would say ssh client is one of the most secure programs out there. We sandbox it because we want to sandbox most programs. If you run into problems, delete the symlink from /usr/local/bin, I don't think is going to make any difference.

gitea-mirror commented

2026-05-05 07:34:47 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jan 13, 2018):

Okay, so it's more of a "Why not?" rather than "This is actually imperative". Cool 😄

@chiraag-nataraj commented on GitHub (Jan 13, 2018): Okay, so it's more of a "Why not?" rather than "This is actually imperative". Cool :smile:

gitea-mirror referenced this issue

2026-05-05 10:09:20 -06:00

[PR #1165] [MERGED] blacklist krunnerrc #3865

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1165

No description provided.

Rows
Columns