On Fri, Sep 06, 2013 at 09:39:33AM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > Now I found next strange behaviour: for account with not found login
> > class sshd refuse GSSAPIAuthentication.
>
> Hmm, I think that's an upstream issue. Try asking on the OpenSSH
And `su`
Slawa Olhovchenkov writes:
> Now I found next strange behaviour: for account with not found login
> class sshd refuse GSSAPIAuthentication.
Hmm, I think that's an upstream issue. Try asking on the OpenSSH
portable mailing list (openssh-unix-...@mindrot.org)
DES
--
Dag-Erling Smørgrav - d...@de
On Tue, Sep 03, 2013 at 04:16:06PM +0200, Dag-Erling Sm??rgrav wrote:
> Lev Serebryakov writes:
> > "Dag-Erling Sm??rgrav" writes:
> > > Actually, sshd already does most of this by farming PAM out to a
> > > child process.
> > And, IMHO, proper way to fix this bug is to fix it here, as "most of
On Wed, 4 Sep 2013, Dag-Erling Sm?rgrav wrote:
> > Maybe it would help if we would have some kind of diagram showing different
> > parts/phases of security- and credentials-related decision making processes?
>
> http://www.youtube.com/watch?v=iRQvrrIhq0k
Thanks a lot! (a little bit lengthy, but
Lev Serebryakov writes:
> I try to write some short list of requirements to this completely new
> solution, where am I wrong? I'm sure, I am, but, where? Thank you.
This is a very good list, and very close to what I was thinking. Some
items, e.g. (1) and (4), seem blindingly obvious to me, but p
Hello, Dag-Erling.
You wrote 4 сентября 2013 г., 15:12:41:
DES> Dmitry Morozovsky writes:
>> Maybe it would help if we would have some kind of diagram showing different
>> parts/phases of security- and credentials-related decision making processes?
DES> http://www.youtube.com/watch?v=iRQvrrIhq0
Dmitry Morozovsky writes:
> Maybe it would help if we would have some kind of diagram showing different
> parts/phases of security- and credentials-related decision making processes?
http://www.youtube.com/watch?v=iRQvrrIhq0k
(if I seem a little confused at times, it's because I was sick and
ha
Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 19:25:11:
DES> I am *not* proposing to move PAM into a daemon. I am proposing
DES> something completely new. I thought I made that clear.
I totally agree with Dmitry Morozovsky's words, so, please, don't read
my words as arguing with you, but r
Hello, Dag-Erling.
You wrote 4 сентября 2013 г., 11:53:14:
DES> Lev Serebryakov writes:
>> Accept input from hostile user is huge security issue per se? Ouch. In
>> modern world there are only hostile users. Yes, all our software has
>> huge security issue, I know that :)
DES> Please look up "pri
Dag-Egling,
On Wed, 4 Sep 2013, Dag-Erling Sm?rgrav wrote:
> I'm not going to answer the rest - it is so full of misconceptions,
> fallacies and incorrect assumptions that I simply don't have the
> energy.
Maybe it would help if we would have some kind of diagram showing different
parts/phases
Lev Serebryakov writes:
> Accept input from hostile user is huge security issue per se? Ouch. In
> modern world there are only hostile users. Yes, all our software has
> huge security issue, I know that :)
Please look up "privilege separation" on Wikipedia so you have at least
*some* idea of what
Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 19:31:13:
>> How does it affect second-most-used-login application -- login(1)?
DES> I don't think login(1) is anywhere near second place - but yes, login(1)
DES> is affected too. Everything that uses PAM is affected by the need to
DES> have a proc
Lev Serebryakov writes:
> Dag-Erling Smørgrav writes:
> > We're not just talking about a bug in sshd. We're talking about a
> > fundamentally broken paradigm which affects *all* applications.
> How does it affect second-most-used-login application -- login(1)?
I don't think login(1) is anywhere
Slawa Olhovchenkov writes:
> Dag-Erling Smørgrav writes:
> > Did you read *anything* that I wrote?
> I read. May be I bad writing, sorry for my english.
No, your English is fine, but I feel like I'm trying to explain to you
that I want to replace a carburetted engine with an injection engine and
Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 18:15:26:
>> login(1) works. It means, that console and telnet works. ftpd(8) doesn't
>> need such excessive session support (single login via ftp? Are you
>> kidding?). So, only sshd(8) is broken. And change (dramatically) well-known
>> programs (l
On Tue, Sep 03, 2013 at 03:23:48PM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > Dag-Erling Sm??rgrav writes:
> > > The application does not need pam_krb5's temporary credential cache. It
> > > is only used internally. Single sign-on is implemented by storing your
> > > c
Lev Serebryakov writes:
> "Dag-Erling Smørgrav" writes:
> > Actually, sshd already does most of this by farming PAM out to a
> > child process.
> And, IMHO, proper way to fix this bug is to fix it here, as "most of
> things" is already done.
Feel free to submit patches.
DES
--
Dag-Erling Smørg
Lev Serebryakov writes:
> login(1) works. It means, that console and telnet works. ftpd(8) doesn't
> need such excessive session support (single login via ftp? Are you
> kidding?). So, only sshd(8) is broken. And change (dramatically) well-known
> programs (like login(1)) and introduce new subsyst
Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 17:23:48:
>> Also, authenticate daemon (in case authenticate daemon call
>> pam_setcred) can't be know what need to transfer (chaneged UID? new
>> enviroment? deleted enviroment?)
DES> Actually, sshd already does most of this by farming PAM out to
Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 17:22:56:
DES> sshd is just one of many applications in the system.
Ooops. I think, have ONE daemon to provide ALL authentication is bad idea.
It crashes. After that you could not login via console, sshd, telnet,
whatever! Only one way -- reboo
Slawa Olhovchenkov writes:
> Dag-Erling Smørgrav writes:
> > The application does not need pam_krb5's temporary credential cache. It
> > is only used internally. Single sign-on is implemented by storing your
> > credentials in a *permanent* credential cache (either a file or KCM)
> > which is i
Lev Serebryakov writes:
> Why do we need separate daemon for it? Why it could not be built-in
> to sshd itself?
sshd is just one of many applications in the system.
> One more daemon -- one more point of failure...
Or you can look at it the other way around: less copy-pasting between
applicati
Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 15:30:43:
>> des@ suggests to have ability to pass env variables from authorization
>> daemon, but anyway, pam_setcred() should be called by shell process
>> (or its parent), and not any process in system, am I right?
DES> Everything pam_setcred() d
On Tue, Sep 03, 2013 at 01:27:04PM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > Dag-Erling Sm??rgrav writes:
> > > Slawa Olhovchenkov writes:
> > > > And how in this case can be resolved situation with PAM credentials
> > > > (Kerberos credentials in may case)?
> > > The
Lev Serebryakov writes:
> des@ suggests to have ability to pass env variables from authorization
> daemon, but anyway, pam_setcred() should be called by shell process
> (or its parent), and not any process in system, am I right?
Everything pam_setcred() does can be done in a separate process, and
Slawa Olhovchenkov writes:
> Dag-Erling Smørgrav writes:
> > Slawa Olhovchenkov writes:
> > > And how in this case can be resolved situation with PAM credentials
> > > (Kerberos credentials in may case)?
> > The application does not need them.
> I need them. I need single sign-on, I need enter p
Hello, Slawa.
You wrote 3 сентября 2013 г., 14:39:22:
>> >> And how in this case can be resolved situation with PAM credentials
>> >> (Kerberos credentials in may case)?
>> DES> The application does not need them.
>> They are written to disk with pam_open_session() and this call should be
>> call
On Tue, Sep 03, 2013 at 02:26:37PM +0400, Lev Serebryakov wrote:
> Hello, Dag-Erling.
> You wrote 3 сентября 2013 г., 13:38:48:
>
> >> And how in this case can be resolved situation with PAM credentials
> >> (Kerberos credentials in may case)?
> DES> The application does not need them.
> They ar
Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 13:38:48:
>> And how in this case can be resolved situation with PAM credentials
>> (Kerberos credentials in may case)?
DES> The application does not need them.
They are written to disk with pam_open_session() and this call should be
called by sshd
On Tue, Sep 03, 2013 at 11:38:48AM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > Dag-Erling Sm??rgrav writes:
> > > When I spoke of passing credentials, I meant process credentials, not
> > > the cached Kerberos credentials - which the application does not need
> > > anyway
Slawa Olhovchenkov writes:
> Dag-Erling Smørgrav writes:
> > When I spoke of passing credentials, I meant process credentials, not
> > the cached Kerberos credentials - which the application does not need
> > anyway. See SCM_CREDS in recv(2) for further information.
> And how in this case can be
On Tue, Sep 03, 2013 at 11:31:09AM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > Dag-Erling Sm??rgrav writes:
> > > The proper solution would be an identification and authentication daemon
> > > with a well-designed RPC interface and mechanisms for transferring
> > > enviro
Slawa Olhovchenkov writes:
> Dag-Erling Smørgrav writes:
> > The proper solution would be an identification and authentication daemon
> > with a well-designed RPC interface and mechanisms for transferring
> > environment variables, descriptors and credentials from the daemon to
> > the applicatio
On Tue, Sep 03, 2013 at 09:51:35AM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > If in this scenario on step 4 insted fork do pthread_create we don't
> > lost stored credentials and (I think) have full-synchronized thread
> > (new thred only work by request from parent and o
Slawa Olhovchenkov writes:
> If in this scenario on step 4 insted fork do pthread_create we don't
> lost stored credentials and (I think) have full-synchronized thread
> (new thred only work by request from parent and only for short time).
It's not quite that simple. When a service module calls
On Mon, Sep 02, 2013 at 07:36:57PM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > Hmmm, now I try to compile sshd with UNSUPPORTED_POSIX_THREADS_HACK and
> > it works (/tmp/krb5cc_ created, kerberosied login to other host
> > working w/o entering password).
>
> So they
Slawa Olhovchenkov writes:
> Hmmm, now I try to compile sshd with UNSUPPORTED_POSIX_THREADS_HACK and
> it works (/tmp/krb5cc_ created, kerberosied login to other host
> working w/o entering password).
So they didn't break the thread version? You shouldn't use it, though,
as the rest of Open
On Fri, Aug 30, 2013 at 02:51:44PM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > Dag-Erling Sm??rgrav writes:
> > > PAM authentication in OpenSSH was broken for non-trivial cases when
> > > privilege separation was implemented. Fixing it properly would be
> > > very diffic
Slawa Olhovchenkov writes:
> Dag-Erling Smørgrav writes:
> > PAM authentication in OpenSSH was broken for non-trivial cases when
> > privilege separation was implemented. Fixing it properly would be
> > very difficult.
> Same behaviour with 'UsePrivilegeSeparation no'. This issuse not in
> priv
On Fri, Aug 30, 2013 at 02:09:26PM +0400, Slawa Olhovchenkov wrote:
> On Fri, Aug 30, 2013 at 09:44:54AM +0200, Dag-Erling Sm??rgrav wrote:
>
> > Slawa Olhovchenkov writes:
> > > I am try to setup single sign-on and found this is imposuble due to
> > > bug in OpenSSH: currently sshd do pam_authe
On Fri, Aug 30, 2013 at 09:44:54AM +0200, Dag-Erling Sm??rgrav wrote:
> Slawa Olhovchenkov writes:
> > I am try to setup single sign-on and found this is imposuble due to
> > bug in OpenSSH: currently sshd do pam_authenticate() and
> > pam_acct_mgmt() from child process, but pam_setcred() from pa
Slawa Olhovchenkov writes:
> I am try to setup single sign-on and found this is imposuble due to
> bug in OpenSSH: currently sshd do pam_authenticate() and
> pam_acct_mgmt() from child process, but pam_setcred() from paren
> proccess. pam_krb5 in pam_sm_setcred() required information from
> pam_sm
On Thu, Aug 29, 2013 at 04:48:44AM +0400, Slawa Olhovchenkov wrote:
> I am try to setup single sign-on and found this is imposuble due to
> bug in OpenSSH: currently sshd do pam_authenticate() and
> pam_acct_mgmt() from child process, but pam_setcred() from paren
> proccess. pam_krb5 in pam_sm_set
I am try to setup single sign-on and found this is imposuble due to
bug in OpenSSH: currently sshd do pam_authenticate() and
pam_acct_mgmt() from child process, but pam_setcred() from paren
proccess. pam_krb5 in pam_sm_setcred() required information from
pam_sm_authenticate and can't work corretly
44 matches
Mail list logo
