Re: AuthorizedKeyCommand ldap

2017-12-12 Thread Edgar Pettijohn 
On Tue, Dec 12, 2017 at 05:25:27PM -0800, Paulm wrote:
> On Tue, Dec 12, 2017 at 09:35:27AM -0700, Dan Becker wrote:
> > On Mon, Dec 11, 2017 at 7:13 PM, Paulm  wrote:
> > 
> > > On Mon, Dec 11, 2017 at 03:49:24PM -0700, Dan Becker wrote:
> > > > I am reading a blog proposing to use the AuthorizedKeyCommand to hook
> > > into
> > > > another authentication mechanism  by calling a shell script
> > > >
> > > > https://blog.heckel.xyz/2015/05/04/openssh-authorizedkeyscommand-with-
> > > fingerprint/
> > > >
> > > > Do I have a valid concern in thinking this might not be a prudent method
> > > of
> > > > authentication ?
> > > >
> > >
> > > I don't know why he uses the term 'dynamic authorized_keys file'.  I
> > > know what he means, but it's not a file.  (When people misuse basic
> > > terms I immediately question their depth of understanding.)
> > >
> > > As for your question - these are some thoughts, not intended to be
> > > comprehensive:
> > >
> > > As I see it, the key will be somewhere - in the authorized_keys file
> > > in the user's home directory, in an LDAP directory, or perhaps
> > > elsewhere.  Regardless of where it's kept, it needs to be secured
> > > against tampering.  Is the local host more secure in that regard than
> > > an LDAP dir?  That depends on the quality of the sysadmins who set up
> > > the server and how the network infrastructure is designed.  The same
> > > applies to any other mechanism for remotely storing public keys.
> > >
> > > sshd(8) will complain if the perms for the user's authorized_key file
> > > aren't correct, so it offers a safe-guard against misconfiguration.
> > >
> > > The mechanism for retrieving the key from a remote server should use
> > > SSL/TLS to validate the server's identity and protect the contents.
> > >
> > > The utility invoked by sshd to fetch the key needs to be secured,
> > > requiring special privileges to modify it.
> > >
> > > Locally, points of attack would be the tool itself or the user's
> > > authorized keys file, or the server's public key.  They're all files,
> > > so file permission restrictions would have to be circumvented.  If the
> > > tool is not written in a type-safe language, then it could create
> > > additional vulnerabilities as well.
> > >
> > > In larger environments, keeping track of authorized_keys files for
> > > users and hosts, making sure they're (only) on the hosts they need to
> > > be on, and keeping them accurate and up-to-date can be tedious and
> > > error prone, even with a config management system.  One could argue
> > > that that method allows for vulnerabilities that would not exist if
> > > the keys were managed centrally.  Again, it depends on the quality of
> > > the sysadmins' work.
> > >
> > > The security requirements in an infrastructure are probably not the
> > > same for all hosts, so you could use a hybrid strategy, using a local
> > > authorzed_keys file for hosts that need greater protection (e.g.,
> > > database servers, firewalls, DMZ hosts, etc) if that makes you more
> > > comfortable. (Generally speaking, I think too much uniformity can
> > > sometimes be a weakness).
> > >
> > >
> > >
> > >
> > Thank you for the above
> > 
> > We have someone suggesting we implement something similar to the above with
> > a twist.
> > 
> > The script they call acts similar to this
> > 
> > user="$1"

case $user in
user1)
do stuff
;;
user2)
do stuff
;;

user3)
do stuff
;;
*)
invalid user stuff
;;
esac
> > hostname="$(hostname)"
> > curl -s -q -m 5 -f -H "Authorization: Token ${secret}" "
> > https://auth.site.com/sshkeys/?user=${user}=${hostname};
> > 2>/dev/null
> > exit $?
> > 
> > 
> > My main concern comes from the fact this process is being ran as root and
> > injecting the username as an arg "$1"
> > 
> > Example :
> > 
> > What happens if someone runs ssh '" -rf /'@host, is there a sanitation
> > in the ssh daemon ?
> 
> Your script will live in the filesystem, potentially executable by
> other programs/users, not just sshd.  Regardless of any kind of input
> sanitation sshd does, your script should probably do it too - or be
> extra careful about how it handles the input.
>

Re: AuthorizedKeyCommand ldap

2017-12-12 Thread Paulm 
On Tue, Dec 12, 2017 at 09:35:27AM -0700, Dan Becker wrote:
> On Mon, Dec 11, 2017 at 7:13 PM, Paulm  wrote:
> 
> > On Mon, Dec 11, 2017 at 03:49:24PM -0700, Dan Becker wrote:
> > > I am reading a blog proposing to use the AuthorizedKeyCommand to hook
> > into
> > > another authentication mechanism  by calling a shell script
> > >
> > > https://blog.heckel.xyz/2015/05/04/openssh-authorizedkeyscommand-with-
> > fingerprint/
> > >
> > > Do I have a valid concern in thinking this might not be a prudent method
> > of
> > > authentication ?
> > >
> >
> > I don't know why he uses the term 'dynamic authorized_keys file'.  I
> > know what he means, but it's not a file.  (When people misuse basic
> > terms I immediately question their depth of understanding.)
> >
> > As for your question - these are some thoughts, not intended to be
> > comprehensive:
> >
> > As I see it, the key will be somewhere - in the authorized_keys file
> > in the user's home directory, in an LDAP directory, or perhaps
> > elsewhere.  Regardless of where it's kept, it needs to be secured
> > against tampering.  Is the local host more secure in that regard than
> > an LDAP dir?  That depends on the quality of the sysadmins who set up
> > the server and how the network infrastructure is designed.  The same
> > applies to any other mechanism for remotely storing public keys.
> >
> > sshd(8) will complain if the perms for the user's authorized_key file
> > aren't correct, so it offers a safe-guard against misconfiguration.
> >
> > The mechanism for retrieving the key from a remote server should use
> > SSL/TLS to validate the server's identity and protect the contents.
> >
> > The utility invoked by sshd to fetch the key needs to be secured,
> > requiring special privileges to modify it.
> >
> > Locally, points of attack would be the tool itself or the user's
> > authorized keys file, or the server's public key.  They're all files,
> > so file permission restrictions would have to be circumvented.  If the
> > tool is not written in a type-safe language, then it could create
> > additional vulnerabilities as well.
> >
> > In larger environments, keeping track of authorized_keys files for
> > users and hosts, making sure they're (only) on the hosts they need to
> > be on, and keeping them accurate and up-to-date can be tedious and
> > error prone, even with a config management system.  One could argue
> > that that method allows for vulnerabilities that would not exist if
> > the keys were managed centrally.  Again, it depends on the quality of
> > the sysadmins' work.
> >
> > The security requirements in an infrastructure are probably not the
> > same for all hosts, so you could use a hybrid strategy, using a local
> > authorzed_keys file for hosts that need greater protection (e.g.,
> > database servers, firewalls, DMZ hosts, etc) if that makes you more
> > comfortable. (Generally speaking, I think too much uniformity can
> > sometimes be a weakness).
> >
> >
> >
> >
> Thank you for the above
> 
> We have someone suggesting we implement something similar to the above with
> a twist.
> 
> The script they call acts similar to this
> 
> user="$1"
> hostname="$(hostname)"
> curl -s -q -m 5 -f -H "Authorization: Token ${secret}" "
> https://auth.site.com/sshkeys/?user=${user}=${hostname};
> 2>/dev/null
> exit $?
> 
> 
> My main concern comes from the fact this process is being ran as root and
> injecting the username as an arg "$1"
> 
> Example :
> 
> What happens if someone runs ssh '" -rf /'@host, is there a sanitation
> in the ssh daemon ?

Also, because you're talking about authentication, I wouldn't be too
casual about handling errors.

Errors should be reported to syslog, not sent to /dev/null.

Re: AuthorizedKeyCommand ldap

2017-12-12 Thread Paulm 
On Tue, Dec 12, 2017 at 09:35:27AM -0700, Dan Becker wrote:
> On Mon, Dec 11, 2017 at 7:13 PM, Paulm  wrote:
> 
> > On Mon, Dec 11, 2017 at 03:49:24PM -0700, Dan Becker wrote:
> > > I am reading a blog proposing to use the AuthorizedKeyCommand to hook
> > into
> > > another authentication mechanism  by calling a shell script
> > >
> > > https://blog.heckel.xyz/2015/05/04/openssh-authorizedkeyscommand-with-
> > fingerprint/
> > >
> > > Do I have a valid concern in thinking this might not be a prudent method
> > of
> > > authentication ?
> > >
> >
> > I don't know why he uses the term 'dynamic authorized_keys file'.  I
> > know what he means, but it's not a file.  (When people misuse basic
> > terms I immediately question their depth of understanding.)
> >
> > As for your question - these are some thoughts, not intended to be
> > comprehensive:
> >
> > As I see it, the key will be somewhere - in the authorized_keys file
> > in the user's home directory, in an LDAP directory, or perhaps
> > elsewhere.  Regardless of where it's kept, it needs to be secured
> > against tampering.  Is the local host more secure in that regard than
> > an LDAP dir?  That depends on the quality of the sysadmins who set up
> > the server and how the network infrastructure is designed.  The same
> > applies to any other mechanism for remotely storing public keys.
> >
> > sshd(8) will complain if the perms for the user's authorized_key file
> > aren't correct, so it offers a safe-guard against misconfiguration.
> >
> > The mechanism for retrieving the key from a remote server should use
> > SSL/TLS to validate the server's identity and protect the contents.
> >
> > The utility invoked by sshd to fetch the key needs to be secured,
> > requiring special privileges to modify it.
> >
> > Locally, points of attack would be the tool itself or the user's
> > authorized keys file, or the server's public key.  They're all files,
> > so file permission restrictions would have to be circumvented.  If the
> > tool is not written in a type-safe language, then it could create
> > additional vulnerabilities as well.
> >
> > In larger environments, keeping track of authorized_keys files for
> > users and hosts, making sure they're (only) on the hosts they need to
> > be on, and keeping them accurate and up-to-date can be tedious and
> > error prone, even with a config management system.  One could argue
> > that that method allows for vulnerabilities that would not exist if
> > the keys were managed centrally.  Again, it depends on the quality of
> > the sysadmins' work.
> >
> > The security requirements in an infrastructure are probably not the
> > same for all hosts, so you could use a hybrid strategy, using a local
> > authorzed_keys file for hosts that need greater protection (e.g.,
> > database servers, firewalls, DMZ hosts, etc) if that makes you more
> > comfortable. (Generally speaking, I think too much uniformity can
> > sometimes be a weakness).
> >
> >
> >
> >
> Thank you for the above
> 
> We have someone suggesting we implement something similar to the above with
> a twist.
> 
> The script they call acts similar to this
> 
> user="$1"
> hostname="$(hostname)"
> curl -s -q -m 5 -f -H "Authorization: Token ${secret}" "
> https://auth.site.com/sshkeys/?user=${user}=${hostname};
> 2>/dev/null
> exit $?
> 
> 
> My main concern comes from the fact this process is being ran as root and
> injecting the username as an arg "$1"
> 
> Example :
> 
> What happens if someone runs ssh '" -rf /'@host, is there a sanitation
> in the ssh daemon ?

Your script will live in the filesystem, potentially executable by
other programs/users, not just sshd.  Regardless of any kind of input
sanitation sshd does, your script should probably do it too - or be
extra careful about how it handles the input.

Re: .Va errno

2017-12-12 Thread Ingo Schwarze 
Hi,

Jeremie Courreges-Anglas wrote on Wed, Dec 06, 2017 at 06:55:22PM +0100:
> On Tue, Dec 05 2017, Jan Stary  wrote:

>> All annotated occurences of "errno" in intro(2) are .Va,
>> except this one which is .Dv - is that intended?
>>
>> The others talk about the "varible" errno, this one is
>> an "identifier which expands to an addressable location",
>> whatever that means.

It means that code like

int *errno_addr = 

may make sense in certain situations, even though it is usually not
needed, and i suspect doing something like that will usually be an
indication of poor program design.  But it is technically valid.

> FWIW, I think it makes sense to speak about errno as a variable (.Va),

So i committed Jan's diff for now, it clearly improves consistency of
the markup and removes a potential source of doubt.

> but to describe that it is actually a preprocessor #define (.Dv)
> under the hood.

Even though it may be hard to invent a different way of actually
implementing the errno variable correctly, the fact that it technically
is a preprocessor macro right now looks like an implementation detail
to me, and i'm not convinced that it needs to be documented.  It
might be possible to convince me otherwise if somebody can explain
good reasons why users ought to be told about it, but i don't feel
like working on documenting that myself.

Yours,
  Ingo


>> Index: intro.2
>> ===
>> RCS file: /cvs/src/lib/libc/sys/intro.2,v
>> retrieving revision 1.65
>> diff -u -p -r1.65 intro.2
>> --- intro.2  5 Sep 2017 03:06:26 -   1.65
>> +++ intro.2  5 Dec 2017 22:01:26 -
>> @@ -51,7 +51,7 @@ Programs may be restricted to a subset o
>>  .\"
>>  .Sh DIAGNOSTICS
>>  Nearly all of the system calls provide an error number via the identifier
>> -.Dv errno ,
>> +.Va errno ,
>>  which expands to an addressable location of type
>>  .Vt int .
>>  The address of

Re: AuthorizedKeyCommand ldap

2017-12-12 Thread Stefan Johnson 
On Tue, Dec 12, 2017 at 10:35 AM, Dan Becker  wrote:

> On Mon, Dec 11, 2017 at 7:13 PM, Paulm  wrote:
>
>
> My main concern comes from the fact this process is being ran as root and
> injecting the username as an arg "$1"
>
> Example :
>
> What happens if someone runs ssh '" -rf /'@host, is there a sanitation
> in the ssh daemon ?
>
>
> --
> --Dan
>

The AuthorizedKeysCommand option is supposed to be used in conjunction
with another option setting that determines the user that will call the
script.
This user should not be root.

The current version uses AuthorizedKeysCommandUser and the man page
states that it is recommended to use a dedicated user that has no other role
on the host than running the authorized keys commands.

The Red Hat Enterprise Linux 6 man page for sshd_config uses this other
option, instead.  AuthorizedKeysCommandRunAs.  This is like the above,
except if it is left empty, it is implied that the command gets run as the
user
logging into the system.

Hope this helps.
Stefan

Re: AuthorizedKeyCommand ldap

2017-12-12 Thread Dan Becker 
On Mon, Dec 11, 2017 at 7:13 PM, Paulm  wrote:

> On Mon, Dec 11, 2017 at 03:49:24PM -0700, Dan Becker wrote:
> > I am reading a blog proposing to use the AuthorizedKeyCommand to hook
> into
> > another authentication mechanism  by calling a shell script
> >
> > https://blog.heckel.xyz/2015/05/04/openssh-authorizedkeyscommand-with-
> fingerprint/
> >
> > Do I have a valid concern in thinking this might not be a prudent method
> of
> > authentication ?
> >
>
> I don't know why he uses the term 'dynamic authorized_keys file'.  I
> know what he means, but it's not a file.  (When people misuse basic
> terms I immediately question their depth of understanding.)
>
> As for your question - these are some thoughts, not intended to be
> comprehensive:
>
> As I see it, the key will be somewhere - in the authorized_keys file
> in the user's home directory, in an LDAP directory, or perhaps
> elsewhere.  Regardless of where it's kept, it needs to be secured
> against tampering.  Is the local host more secure in that regard than
> an LDAP dir?  That depends on the quality of the sysadmins who set up
> the server and how the network infrastructure is designed.  The same
> applies to any other mechanism for remotely storing public keys.
>
> sshd(8) will complain if the perms for the user's authorized_key file
> aren't correct, so it offers a safe-guard against misconfiguration.
>
> The mechanism for retrieving the key from a remote server should use
> SSL/TLS to validate the server's identity and protect the contents.
>
> The utility invoked by sshd to fetch the key needs to be secured,
> requiring special privileges to modify it.
>
> Locally, points of attack would be the tool itself or the user's
> authorized keys file, or the server's public key.  They're all files,
> so file permission restrictions would have to be circumvented.  If the
> tool is not written in a type-safe language, then it could create
> additional vulnerabilities as well.
>
> In larger environments, keeping track of authorized_keys files for
> users and hosts, making sure they're (only) on the hosts they need to
> be on, and keeping them accurate and up-to-date can be tedious and
> error prone, even with a config management system.  One could argue
> that that method allows for vulnerabilities that would not exist if
> the keys were managed centrally.  Again, it depends on the quality of
> the sysadmins' work.
>
> The security requirements in an infrastructure are probably not the
> same for all hosts, so you could use a hybrid strategy, using a local
> authorzed_keys file for hosts that need greater protection (e.g.,
> database servers, firewalls, DMZ hosts, etc) if that makes you more
> comfortable. (Generally speaking, I think too much uniformity can
> sometimes be a weakness).
>
>
>
>
Thank you for the above

We have someone suggesting we implement something similar to the above with
a twist.

The script they call acts similar to this

user="$1"
hostname="$(hostname)"
curl -s -q -m 5 -f -H "Authorization: Token ${secret}" "
https://auth.site.com/sshkeys/?user=${user}=${hostname};
2>/dev/null
exit $?


My main concern comes from the fact this process is being ran as root and
injecting the username as an arg "$1"

Example :

What happens if someone runs ssh '" -rf /'@host, is there a sanitation
in the ssh daemon ?






-- 
--Dan