[Bug 2647] Tracking bug for OpenSSH 7.5 release

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2647
Bug 2647 depends on bug 2674, which changed state.

Bug 2674 Summary: [CONFIRMED] channel 4: open failed: administratively 
prohibited: open failed
https://bugzilla.mindrot.org/show_bug.cgi?id=2674

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching the reporter of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2647] Tracking bug for OpenSSH 7.5 release

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2647

Darren Tucker  changed:

   What|Removed |Added

 Depends on||2674


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2674
[Bug 2674] [CONFIRMED] channel 4: open failed: administratively
prohibited: open failed
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching the reporter of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2674] [CONFIRMED] channel 4: open failed: administratively prohibited: open failed

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2674

Darren Tucker  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 Blocks||2647
 CC||dtuc...@zip.com.au

--- Comment #1 from Darren Tucker  ---
A slightly simplified version of the patch you referred to has just
been committed and will be in the 7.5 release.

Thanks.


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2647
[Bug 2647] Tracking bug for OpenSSH 7.5 release
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2625] Support Capabilities for ssh client port forwarding

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2625

--- Comment #9 from Richard E. Silverman  ---
Ah, I was only thinking about the client-side case, since that is how
this bug report started:

> I think openssh-client should allow use port forwarding not only for
> root user. CAP_NET_BIND_SERVICE enough to use privileged ports.

... and in fact I came across this bugzilla entry because I was about
to file one for the same problem with the client-side UsePrivilegedPort
option, which is silently turned off if the euid is not 0:

[ssh.c]
if (original_effective_uid != 0)
options.use_privileged_port = 0;

... which is similarly inaccurate.

> These are solvable, eg by temporarily_use_uid() and/or by testing
> binds during config parsing, but it's not a simple case of 
> "delete those checks and YOLO".

Agreed, on the server side where privilege management is involved; I
was advocating a different approach to the problem rather than giving a
detailed, finished solution. On the client just that should be almost
enough. If we want to preserve the current behavior on the client --
that the connection succeeds anyway -- then it would try to bind the
low port, and if it gets EPERM (or any error?), retry without the
low-port restriction before giving up.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2625] Support Capabilities for ssh client port forwarding

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2625

--- Comment #8 from Darren Tucker  ---
(In reply to Richard E. Silverman from comment #7)
> This should be addressed, but I disagree with the proposed solution
> here. The real problem is not that ssh checks its euid

Well it checks the uid of the user logging in, which may or may not be
the euid of the process.

In the case where sshd is running with UsePrivilegeSeparation=no the
process making the bind() calls is running as root even when handling
non-root logins.  Similarly ssh can be installed setuid, although it's
not common any more.  If you don't have some kind of check (or do
temporarily_use_uid()), well, things like
https://bugs.chromium.org/p/project-zero/issues/detail?id=1010 happen.

Currently these errors are currently caught at config parse time.  Your
proposal wouldn't detect them until later when the connection was
already up.

These are solvable, eg by temporarily_use_uid() and/or by testing binds
during config parsing, but it's not a simple case of "delete those
checks and YOLO".

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2625] Support Capabilities for ssh client port forwarding

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2625

Richard E. Silverman  changed:

   What|Removed |Added

 CC||r...@qoxp.net

--- Comment #7 from Richard E. Silverman  ---
Hello,

This should be addressed, but I disagree with the proposed solution
here. The real problem is not that ssh checks its euid -- it is that
ssh tries to guess whether the kernel will allow it to bind a low port,
but cannot in principle know what is required for that; that's the
kernel's job, and will change depending on the security facilities in
use on a particular system. It's like refusing to try to open a file if
the mode bits don't seem to allow you to: maybe an ACL would allow it.
Or deciding that you must be able to open the file, but then finding
that you can't because SELinux is enabled, and the policy blocks it.
Programs should not second-guess the kernel: ssh should just try to
bind the port, and report the result.

Pleasantly, this also gets rid of all the issues discussed here around
the usage of libcap etc.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs