openssh bugs - Sep 2014 - [Bug 2276] New: AuthorizedKeysCommand: add an option for alternate owner

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

            Bug ID: 2276
           Summary: AuthorizedKeysCommand: add an option for alternate
                    owner
           Product: Portable OpenSSH
           Version: 6.6p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: alon.barlev at gmail.com

Created attachment 2474
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2474&action=edit
AuthorizedKeysCommand-add-an-option-for-alternate-ow.patch

Currently the owner of AuthorizedKeysCommand must be root.

A setup in which sshd is running as non root, can enjoy a complete
and secure environment even if the AuthorizedKeysCommand is owned by a
different user.

This patch adds AuthorizedKeysCommandOwner option to control the
ownership check of the AuthorizedKeysCommand. Default is root, so no
change is done without explicit request.

---

Discussed without response at[1], I thought I give it a chance here.
Looking forward to fix of bug#2081, this and some others to make it
possible to run sshd in complete unprivilged mode, while enjoying all
benefits provided by the implmentation.

Thanks!

[1]
http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-June/032696.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Alon Bar-Lev <alon.barlev at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://github.com/openssh/
                   |                            |openssh-portable/pull/3

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Alon Bar-Lev <alon.barlev at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2474|0                           |1
        is obsolete|                            |

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
I think it would be reasonable to relax the permission check to allow
the command to be owned by the user who started sshd as well as root. I
don't think another option is warranted or necessary.

-- 
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.

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

--- Comment #2 from Alon Bar-Lev <alon.barlev at gmail.com> ---
(In reply to Damien Miller from comment #1)
> I think it would be reasonable to relax the permission check to
> allow the command to be owned by the user who started sshd as well
> as root. I don't think another option is warranted or necessary.
I thought that the original code was designed to block the user that
ssh into local to modify the command, I did not want to violate this
restriction.

Did I understand incorrectly why we limit ownership?

-- 
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.

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

--- Comment #3 from Alon Bar-Lev <alon.barlev at gmail.com> ---
Hello Damien,
Can you please reply to comment#2 so I can submit a new patch if
required?
Thanks!

-- 
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.

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

--- Comment #4 from Alon Bar-Lev <alon.barlev at gmail.com> ---
Rebased on top of master.

Can you please reply to question at comment#2? It will simplify the
implementation but I think there is potential security cost.

(In reply to Alon Bar-Lev from comment #2)
> (In reply to Damien Miller from comment #1)
> > I think it would be reasonable to relax the permission check to
> > allow the command to be owned by the user who started sshd as well
> > as root. I don't think another option is warranted or necessary.
> 
> I thought that the original code was designed to block the user that
> ssh into local to modify the command, I did not want to violate this
> restriction.
> 
> Did I understand incorrectly why we limit ownership?
-- 
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.

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

--- Comment #5 from Alon Bar-Lev <alon.barlev at gmail.com> ---
Created attachment 2558
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2558&action=edit
AuthorizedKeysCommand-add-an-option-for-alternate-ow.patch

-- 
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.

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

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
(In reply to Alon Bar-Lev from comment #2)
> (In reply to Damien Miller from comment #1)
> > I think it would be reasonable to relax the permission check to
> > allow the command to be owned by the user who started sshd as well
> > as root. I don't think another option is warranted or necessary.
> 
> I thought that the original code was designed to block the user that
> ssh into local to modify the command, I did not want to violate this
> restriction.
> 
> Did I understand incorrectly why we limit ownership?
That is indeed the intent, and allowing the user who started sshd in
addition to root doesn't violate it.

-- 
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.

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

--- Comment #7 from Alon Bar-Lev <alon.barlev at gmail.com> ---
(In reply to Damien Miller from comment #6)
> (In reply to Alon Bar-Lev from comment #2)
> > (In reply to Damien Miller from comment #1)
> > > I think it would be reasonable to relax the permission check to
> > > allow the command to be owned by the user who started sshd as
well
> > > as root. I don't think another option is warranted or
necessary.
> > 
> > I thought that the original code was designed to block the user that
> > ssh into local to modify the command, I did not want to violate this
> > restriction.
> > 
> > Did I understand incorrectly why we limit ownership?
> 
> That is indeed the intent, and allowing the user who started sshd in
> addition to root doesn't violate it.
I am very sorry, but must understand that fully.

If I start sshd using unprivileged user let's say sshuser, the sshd
cannot setuid, so it is left within sshuser context, and be able to
modify the authorized keys command as it is the owner.

Doesn't it violates the original intention?

-- 
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.

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

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
The idea is to prevent the _target_ user from modifying
AuthorizedUsersCommand, not the user who starts sshd.

If the user can start sshd, then they can hardly do more damage by
running AuthorizedUsersCommand...

-- 
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.

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

--- Comment #9 from Alon Bar-Lev <alon.barlev at gmail.com> ---
(In reply to Damien Miller from comment #8)
> The idea is to prevent the _target_ user from modifying
> AuthorizedUsersCommand, not the user who starts sshd.
> 
> If the user can start sshd, then they can hardly do more damage by
> running AuthorizedUsersCommand...
I understand. But fortunately, sshd can also run under non root account
that have no special permissions nor can switch user. This is very
useful for git or backup usages in which one wants to completely
isolate the remote.

In this use case, running sshd under git user, will enable access the
machine using git at host, while authenticating based on authorized keys
command, this works perfectly.

The only missing bit is to enable this command to be owned by different
account than root.

Owning it by the user started sshd in this case is the same as owning
as the _target_ user.

This is why I added a configuration option.

-- 
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.

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

--- Comment #10 from Alon Bar-Lev <alon.barlev at gmail.com> ---
Created attachment 2559
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2559&action=edit
AuthorizedKeysCommand-owner-can-be-the-one-that-star.patch

This is the alternative of having the owner as user who started sshd.

-- 
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.

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

Alon Bar-Lev <alon.barlev at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2558|0                           |1
        is obsolete|                            |

--- Comment #11 from Alon Bar-Lev <alon.barlev at gmail.com> ---
Created attachment 2560
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2560&action=edit
AuthorizedKeysCommand-add-an-option-for-alternate-ow.patch

This is the alternative of having a configuration option.

I like it more.

-- 
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.