Re: Old Stuff

[Slawa Olhovchenkov]

On Wed, Jul 24, 2019 at 02:56:47PM -0400, Robert Simmons wrote:

> The safer part of my speculation is specifically based on being less code
> to maintain overall. More resources devoted to a smaller code base.

Best of all is completly remove any code: no code -- no hole.

> On Wed, Jul 24, 2019 at 1:26 PM Igor Mozolevsky 
> wrote:
> 
> >
> >
> > On Wednesday, 24 July 2019, Robert Simmons wrote:
> >
> > Lolz, right? :-
> >
> > > I wonder if FreeBSD should drop support for 32bit? Clean out and remove
> > all
> > > of it. It should make the code base easier to maintain, cleaner, and
> > safer.
> >
> > Because nobody has a 32bit computer nowadays??? Similarly, you got any
> > empirical evidence to back up the "... safer" part of your speculation?
> >
> > > In this same vein, let's deprecate and remove things like telnet and ftp.
> >
> >
> > How does the saying go, "if you think that encryption is the solution to
> > your problem then you don't understand neither encryption nor your
> > problem"? I would hazard a guess that over 95% of encrypted traffic needn't
> > be encrypted at all, but no commercial interest developed "integrity over
> > http" so we all have to suffer "encryption under http" instead.
> >
> >
> > --
> >
> > Igor M.
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Slawa Olhovchenkov]

On Tue, Dec 05, 2017 at 01:13:25PM -0800, Yuri wrote:

> On 12/05/17 13:04, Eugene Grosbein wrote:
> > It is illusion that https is more secure than unencrypted http in a sense 
> > of MITM
> > just because of encryption, it is not.
> 
> 
> It *is* more secure.

https don't work frequent than http and this is not secure.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: fbsd11 & sshv1

[Slawa Olhovchenkov]

On Wed, Feb 01, 2017 at 05:31:28AM -0800, Roger Marquis wrote:

> > I believe FreeBSD should just have a slave port with OpenSSH 7.4, used only
> > for SSHv1. People using such port should know the consequences of it.
> 
> This could be a good candidate for a new ports category,
> 
>/usr/ports/legacy
> 
> If implemented there is a lot of code, in both ports and base, that
> should be relocated.  (telnet, rsh/rlogin/rcp/..., nis/yp, rpc.*, cvs,
> games, ppp, sendmail, finger, ...)

...nfs, kerberos, sshv2, top, GENERIC, cp, mv, ifconfig, netstat...
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: GOST in OPENSSL_BASE

[Slawa Olhovchenkov]

On Mon, Jul 18, 2016 at 12:39:46PM -0400, Jung-uk Kim wrote:

> On 07/18/16 08:12 AM, Mathieu Arnold wrote:
> > Hi,
> > 
> > +--On 11 juillet 2016 22:56:00 +0300 Slawa Olhovchenkov <s...@zxy.spb.ru>
> > wrote:
> > | On Mon, Jul 11, 2016 at 03:00:39PM -0400, Jung-uk Kim wrote:
> > |> > .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
> > |> > ${SSL_DEFAULT} == base BROKEN= OpenSSL from the base system does not
> > |> > support GOST, add \ DEFAULT_VERSIONS+=ssl=openssl to your
> > |> > /etc/make.conf and rebuild everything \ that needs SSL.
> > |> > .endif
> > |> 
> > |> FreeBSD 9.3 is still supported but GOST is not available there.  It
> > | 
> > | Thanks for clarifications.
> > | 
> > |> seems the ports maintainer didn't want to break it on 9.3 (CC added).
> > |> Version check may be needed there.
> > | 
> > | Thanks!
> > 
> > 
> > The idea is that you can't have mixed openssl usage.  If you link half your
> > ports with openssl from base, and half with openssl from ports, you are
> > going to have dragons attacks, and core dumps.  Also, if you are using
> > openssl from ports, you cannot use GSSAPI from base, for the same reasons.
> 
> Exactly.  That's why we should *allow* using base OpenSSL for 10.x and
> later because many packages are already linked against base OpenSSL by
> default.

Ports still refuse to GOST from base openssl.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Heimdal in base

[Slawa Olhovchenkov]

On Wed, Sep 14, 2016 at 10:07:15PM -0400, Garrett Wollman wrote:

> < 
> said:
> 
> > Well, it's definitely too late for 11, now.
> 
> > But, Debian is preparing to remove their heimdal package entirely,
> > imminently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728
> 
> The primary issue, so far as I can see, is that Heimdal and MIT were
> only compatible in the parts of the API that were formally
> standardized.  For those of us who need MIT (to have a working kadmin,
> for example), that has pretty much always boiled down to completely
> disabling Heimdal in base (and anything that depends on it, like
> OpenSSH, pam_krb5, and GSSAPI-authenticated NFS), and installing
> replacement bits from ports/packages.
> 
> If we're going to remove Heimdal from base, we should completely
> deorbit (or disable, as appropriate) all of the things that depend on
> it, and make sure that there are ports that provide replacement
> functionality.  (AFAIK the only thing missing is gssd, the user-mode
> side of the authenticated NFS support.)  My bet would be that very few
> FreeBSD users actually take advantage of this support, and unless
> they're running in an all-FreeBSD or all-Heimdal shop probably have to
> install MIT Kerberos anyway.

I am use gssd. For $HOME over NFS.

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD - a lesson in poor defaults?

[Slawa Olhovchenkov]

On Wed, Jul 13, 2016 at 09:38:59AM +0200, Steve Clement wrote:

> Dear List,
> 
> Not sure this has been shared here:
> 
> https://vez.mrsk.me/freebsd-defaults.txt
> 
> Some good points, others not so…
> 
> Nevertheless a good read and food for thought and discussion.

Most points is just inconvenience w/o security.
IMHO, yes.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: GOST in OPENSSL_BASE

[Slawa Olhovchenkov]

On Mon, Jul 11, 2016 at 07:48:44PM +0300, Andrey Chernov wrote:

> On 11.07.2016 19:29, Slawa Olhovchenkov wrote:
> > On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote:
> > 
> >>
> >>
> >> On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote:
> >>>
> >>> I.e. GOST will be available in openssl.
> >>> Under BSD-like license.
> >>> Can be this engine import in base system and enabled at time 1.1.0?
> >>> And can be GOST enabled now?
> >>>
> >>
> >> I think the wrong question is being asked here. Instead we need to focus
> >> on decoupling openssl from base so this can all be handled by ports.
> > 
> > This is wrong direction with current policy.
> > ports: unsupported by FreeBSD core and securite team, no guaranted to 
> > comaptible
> > between options and applications.
> > 
> > base: supported by FreeBSD core and securite team, covered by CI,
> > checked for forward and backward API and ABI compatibility.
> > 
> 
> Ports are supported by secteam, and recently I notice "headsup" mail
> with intention to make base openssl private and switch all ports to
> security/openssl port.

I mean `support` is commit reviewing, auditing and etc.
Secteam do it for ports?

> Adding of GOST as 3rd party plugin is technically possible in both
> (base, ports) cases, the rest of decision is up to FreeBSD openssl
> maintainers and possible contributors efforts.
> 
> I need to specially point to "patches" section of the 3rd party GOST
> plugin, from just viewing I don't understand, are those additional
> openssl patches should be applied to openssl for GOST, or they are just
> reflect existent changes in the openssl.
> 
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: GOST in OPENSSL_BASE

[Slawa Olhovchenkov]

On Mon, Jul 11, 2016 at 03:00:39PM -0400, Jung-uk Kim wrote:

> On 07/11/16 02:41 PM, Slawa Olhovchenkov wrote:
> > On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
> > 
> >> On 07/10/16 10:10 AM, Andrey Chernov wrote:
> >>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> >>>> I am surprised lack of support GOST in openssl-base.
> >>>> Can be this enabled before 11.0 released?
> >>>
> >>> AFAIK openssl maintainers says something like they can't support this
> >>> code and it will become rotten shortly with new changes, so they drop it.
> >>
> >> [OpenSSL-maintainer-for-the-base hat on]
> >>
> >> GOST is supported on FreeBSD 10.x and 11.x.  We will not drop it on
> >> these branches unless secteam explicitly ask us to do so.  However, we
> >> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
> >>
> >> [OpenSSL-maintainer-for-the-base hat off]
> >>
> >> Jung-uk Kim
> >>
> > 
> > Thanks!
> > 
> > May be need file PR for dns/bind910?
> > 
> > # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> > .include 
> > 
> > .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) && 
> > ${SSL_DEFAULT} == base
> > BROKEN= OpenSSL from the base system does not support GOST, add \
> > DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and rebuild 
> > everything \
> > that needs SSL.
> > .endif
> 
> FreeBSD 9.3 is still supported but GOST is not available there.  It

Thanks for clarifications.

> seems the ports maintainer didn't want to break it on 9.3 (CC added).
> Version check may be needed there.

Thanks!

> Jung-uk Kim
> 
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: GOST in OPENSSL_BASE

[Slawa Olhovchenkov]

On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:

> On 07/10/16 10:10 AM, Andrey Chernov wrote:
> > On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> >> I am surprised lack of support GOST in openssl-base.
> >> Can be this enabled before 11.0 released?
> > 
> > AFAIK openssl maintainers says something like they can't support this
> > code and it will become rotten shortly with new changes, so they drop it.
> 
> [OpenSSL-maintainer-for-the-base hat on]
> 
> GOST is supported on FreeBSD 10.x and 11.x.  We will not drop it on
> these branches unless secteam explicitly ask us to do so.  However, we
> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
> 
> [OpenSSL-maintainer-for-the-base hat off]
> 
> Jung-uk Kim
> 

Thanks!

May be need file PR for dns/bind910?

# grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
.include 

.if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) && ${SSL_DEFAULT} 
== base
BROKEN= OpenSSL from the base system does not support GOST, add \
DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and rebuild 
everything \
that needs SSL.
.endif
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: GOST in OPENSSL_BASE

[Slawa Olhovchenkov]

On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote:

> 
> 
> On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote:
> > 
> > I.e. GOST will be available in openssl.
> > Under BSD-like license.
> > Can be this engine import in base system and enabled at time 1.1.0?
> > And can be GOST enabled now?
> > 
> 
> I think the wrong question is being asked here. Instead we need to focus
> on decoupling openssl from base so this can all be handled by ports.

This is wrong direction with current policy.
ports: unsupported by FreeBSD core and securite team, no guaranted to comaptible
between options and applications.

base: supported by FreeBSD core and securite team, covered by CI,
checked for forward and backward API and ABI compatibility.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: GOST in OPENSSL_BASE

[Slawa Olhovchenkov]

On Sun, Jul 10, 2016 at 06:28:04PM +0300, Andrey Chernov wrote:

> On 10.07.2016 18:13, Andrey Chernov wrote:
> > On 10.07.2016 18:12, Andrey Chernov wrote:
> >> On 10.07.2016 18:01, Slawa Olhovchenkov wrote:
> >>> On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote:
> >>>
> >>>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> >>>>> I am surprised lack of support GOST in openssl-base.
> >>>>> Can be this enabled before 11.0 released?
> >>>>
> >>>> AFAIK openssl maintainers says something like they can't support this
> >>>> code and it will become rotten shortly with new changes, so they drop it.
> >>>>
> >>>
> >>> Upstream or FreeBSD maintainers?
> >>>
> >>
> >> Openssl maintainers.
> >>
> > I.e. upstream.
> > 
> They mean built-in one, dropped from openssl 1.1.0 and above. It is
> still available as 3rd party at:
> https://github.com/gost-engine/engine

I.e. GOST will be available in openssl.
Under BSD-like license.
Can be this engine import in base system and enabled at time 1.1.0?
And can be GOST enabled now?

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

GOST in OPENSSL_BASE

[Slawa Olhovchenkov]

I am surprised lack of support GOST in openssl-base.
Can be this enabled before 11.0 released?

Subject: svn commit: r412619 - in head/dns: bind9-devel bind910 bind99

Author: mat
Date: Wed Apr  6 13:53:09 2016
New Revision: 412619
URL: https://svnweb.freebsd.org/changeset/ports/412619

Log:
  Stop bringing in OpenSSL from ports, it builds fine with the base one on
  9, and WITH_OPENSSL_PORT does not belong in a port's Makefile anyway.
  
  Not bumping PORTREVISION because:
  - if you are building with poudriere, it will detect that a dependency
has changed and rebuild it.
  - if you are building from ports, you will have OpenSSL from ports
installed, and it will choose to use it.
  
  Sponsored by: Absolight

+.include 
+
+.if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) && 
defined(WITH_OPENSSL_BASE)
+BROKEN=OpenSSL from the base system does not support GOST, add \
+   WITH_OPENSSL_PORT=yes to your /etc/make.conf and rebuild everything \
+   that needs SSL.
+.endif
+
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: unbound and ntp issuse

[Slawa Olhovchenkov]

On Fri, Jun 10, 2016 at 12:53:04PM +0100, krad wrote:

> Pretty much every box requires some form of configuration so its a moot
> point. IF you want automated deployment you will almost certainly be
> building a pxe or prepreared usb/cd image of some sort. In which case you
> include these settings in the deployed rc.conf.

This sound like "installer and default config not need, use ansible
for all"

> On 9 June 2016 at 14:37, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> 
> > On Thu, Jun 09, 2016 at 02:29:09PM +0100, krad wrote:
> >
> > > I doubt that will happen as you are asking to pollute every release
> > > installation for an edge condition when  there is numerous work arounds
> > > that would be acceptable to most.   eg two lines in rc.conf will fix the
> > > issue.
> >
> > This manual editing will be required by every install on RPi, for
> > example.
> >
> > Also, this issuse hard to dignostics by average user.
> >
> > > On 9 June 2016 at 09:04, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> > >
> > > > On Thu, Jun 09, 2016 at 08:39:42AM +0100, krad wrote:
> > > >
> > > > > googles will be pretty static, but i would just use them as a one
> > off, ie
> > > > > with ntpdate
> > > >
> > > > i am talk about freebsd system/project.
> > > >
> > > > >
> > > > > On 8 June 2016 at 10:48, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> > > > >
> > > > > > On Wed, Jun 08, 2016 at 02:29:29AM +0200, Dag-Erling Smørgrav
> > wrote:
> > > > > >
> > > > > > > Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > > > > > > > IMHO, ntp.conf need to include some numeric IP of public ntp
> > > > servers.
> > > > > > >
> > > > > > > https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
> > > > > > >
> > https://en.wikipedia.org/wiki/Poul-Henning_Kamp#Dispute_with_D-Link
> > > > > >
> > > > > > What you suggestion?
> > > > > >
> > > > > > ___
> > > > > > freebsd-sta...@freebsd.org mailing list
> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > > > To unsubscribe, send any mail to "
> > > > freebsd-stable-unsubscr...@freebsd.org"
> > > > > >
> > > >
> >
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: unbound and ntp issuse

[Slawa Olhovchenkov]

On Thu, Jun 09, 2016 at 02:29:09PM +0100, krad wrote:

> I doubt that will happen as you are asking to pollute every release
> installation for an edge condition when  there is numerous work arounds
> that would be acceptable to most.   eg two lines in rc.conf will fix the
> issue.

This manual editing will be required by every install on RPi, for
example.

Also, this issuse hard to dignostics by average user.

> On 9 June 2016 at 09:04, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> 
> > On Thu, Jun 09, 2016 at 08:39:42AM +0100, krad wrote:
> >
> > > googles will be pretty static, but i would just use them as a one off, ie
> > > with ntpdate
> >
> > i am talk about freebsd system/project.
> >
> > >
> > > On 8 June 2016 at 10:48, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> > >
> > > > On Wed, Jun 08, 2016 at 02:29:29AM +0200, Dag-Erling Smørgrav wrote:
> > > >
> > > > > Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > > > > > IMHO, ntp.conf need to include some numeric IP of public ntp
> > servers.
> > > > >
> > > > > https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
> > > > > https://en.wikipedia.org/wiki/Poul-Henning_Kamp#Dispute_with_D-Link
> > > >
> > > > What you suggestion?
> > > >
> > > > ___
> > > > freebsd-sta...@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > To unsubscribe, send any mail to "
> > freebsd-stable-unsubscr...@freebsd.org"
> > > >
> >
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: unbound and ntp issuse

[Slawa Olhovchenkov]

On Thu, Jun 09, 2016 at 08:39:42AM +0100, krad wrote:

> googles will be pretty static, but i would just use them as a one off, ie
> with ntpdate

i am talk about freebsd system/project.

> 
> On 8 June 2016 at 10:48, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> 
> > On Wed, Jun 08, 2016 at 02:29:29AM +0200, Dag-Erling Smørgrav wrote:
> >
> > > Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > > > IMHO, ntp.conf need to include some numeric IP of public ntp servers.
> > >
> > > https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
> > > https://en.wikipedia.org/wiki/Poul-Henning_Kamp#Dispute_with_D-Link
> >
> > What you suggestion?
> >
> > ___
> > freebsd-sta...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> >
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: unbound and ntp issuse

[Slawa Olhovchenkov]

On Wed, Jun 08, 2016 at 02:29:29AM +0200, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > IMHO, ntp.conf need to include some numeric IP of public ntp servers.
> 
> https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
> https://en.wikipedia.org/wiki/Poul-Henning_Kamp#Dispute_with_D-Link

What you suggestion?

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: unbound and ntp issuse

[Slawa Olhovchenkov]

On Fri, Jun 03, 2016 at 02:34:18PM -0400, Lowell Gilbert wrote:

> Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> 
> > Default install with local_unbound and ntpd can't be functional with
> > incorrect date/time in BIOS:
> >
> > Unbound requred correct time for DNSSEC check and refuseing queries
> > ("Jul 1 20:17:29 yellowrat unbound: [3444:0] info: failed to prime
> > trust anchor -- DNSKEY rrset is not secure . DNSKEY IN")
> >
> > ntpd don't have any numeric IP of ntp servers in ntp.conf -- only
> > symbolic names like 0.freebsd.pool.ntp.org, as result -- can't
> > resolve (see above, about DNSKEY).
> 
> I can't see how this would happen. DNSSEC doesn't seem to be required in
> a regular install as far as I can see. Certainly I don't have any

I don't know reasson for enforcing DNSSEC in regular install.
I am just select `local_unbound` at setup time and enter `127.0.0.1` as
nameserver address.

> problem on any of my systems, and I've never configured an anchor on the
> internal systems.
> 
> > IMHO, ntp.conf need to include some numeric IP of public ntp servers.
> 
> Ouch; that's a terrible idea, for several different reasons.

What else?
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

unbound and ntp issuse

[Slawa Olhovchenkov]

Default install with local_unbound and ntpd can't be functional with
incorrect date/time in BIOS:

Unbound requred correct time for DNSSEC check and refuseing queries
("Jul  1 20:17:29 yellowrat unbound: [3444:0] info: failed to prime trust 
anchor -- DNSKEY rrset is not secure . DNSKEY IN")

ntpd don't have any numeric IP of ntp servers in ntp.conf -- only
symbolic names like 0.freebsd.pool.ntp.org, as result -- can't
resolve (see above, about DNSKEY).

IMHO, ntp.conf need to include some numeric IP of public ntp servers.

# date
Tue Jul  1 20:36:31 MSD 2008


___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: HPN and None options in OpenSSH

[Slawa Olhovchenkov]

On Fri, Jan 22, 2016 at 03:31:22PM +0100, Dag-Erling Smørgrav wrote:

> The HPN and None cipher patches have been removed from FreeBSD-CURRENT.
> I intend to remove them from FreeBSD-STABLE this weekend.

Can you do some small discurs about ssh+kerberos?
I am try to use FreeBSD with $HOME over kerberoized NFS.
For kerberoized NFS gssd need to find cache file "called
/tmp/krb5cc_, where  is the effective uid for the RPC
caller" (from `man gssd`).

sshd contrary create cache file for received ticket called
/tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
this strong security  requirement or [FreeBSD/upstream] can be patched
(or introduce option) to use /tmp/krb5cc_ as cache file for
received ticket?
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: HPN and None options in OpenSSH

[Slawa Olhovchenkov]

On Sun, Jan 24, 2016 at 03:50:45PM +0100, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > Can you do some small discurs about ssh+kerberos?
> > I am try to use FreeBSD with $HOME over kerberoized NFS.
> > For kerberoized NFS gssd need to find cache file "called
> > /tmp/krb5cc_, where  is the effective uid for the RPC
> > caller" (from `man gssd`).
> >
> > sshd contrary create cache file for received ticket called
> > /tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
> > this strong security  requirement or [FreeBSD/upstream] can be patched
> > (or introduce option) to use /tmp/krb5cc_ as cache file for
> > received ticket?
> 
> I wasn't aware of that.  It should be easy to patch, but in the

Yes, I am already do ugly patch for me (2 files need to patch), but patch in
upstream preffered.

> meantime, you can try something like this in .bashrc or whatever:

Imposible. For accessing .bashrc on kerberoized NFS need correct 
/tmp/krb5cc_.

> krb5cc_uid="/tmp/krb5cc_$(id -u)"
> if [ -n "${KRB5CCNAME}" -a "${KRB5CCNAME}" != "${krb5ccuid}" ] ; then
> if mv "${KRB5CCNAME}" "${krb5ccuid}" ; then
> export KRB5CCNAME="${krb5ccuid}"
> else
> echo "Unable to rename krb5 credential cache" >&2
> fi
> fi
> unset krb5ccuid
> 
> DES
> -- 
> Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: HPN and None options in OpenSSH

[Slawa Olhovchenkov]

On Sun, Jan 24, 2016 at 04:21:17PM +0100, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > OK, what about tcsh, zsh, fish and scp/sftp?
> 
> I apologize for trying to help you out by suggesting a hack that works
> at least some of the time until I can get a permanent fix in.  I should
> instead have hopped in my time machine, jumped back a few years, and
> fixed the bug before it affected you.  No hard feelings?

Sorry about not clear exposition.
I think this is not hack nor permanent solution and decline
modification ssh source.

I am already have working solution (localy apllied patch at time `make
release`). 

I can show my ugly patch, but I think his partially not clear and not
all edge cases checked.


___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:

> Bryan Drewery  writes:
> > Another thing that I did with the port was restore the tcpwrapper
> > support that upstream removed. Again, if we decide it is not worth
> > keeping in base I will remove it as default in the port.
> 
> I want to keep tcpwrapper support - it is another reason why I still
> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
> less intrusive than HPN.

Can you explain what is problem?
I am see openssh in base and openssh in ports (more recent version)
with same functionaly patches.
You talk about trouble to upgrade. What is root?
openssh in base have different vendor and/or license?
Or something else?

PS: As I today know, kerberos heimdal is practicaly dead as opensource
project. Have FreeBSD planed switch to MIT Kerberos?
I am know about security/krb5.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Tue, Nov 10, 2015 at 09:52:16AM -0800, John-Mark Gurney wrote:

> Dag-Erling Smrgrav wrote this message on Tue, Nov 10, 2015 at 10:42 +0100:
> > Therefore, I would like to remove the HPN patches from base and refer
> > anyone who really needs them to the openssh-portable port, which has
> > them as a default option.  I would also like to remove the NONE cipher
> > patch, which is also available in the port (off by default, just like in
> > base).
> 
> My vote is to remove the HPN patches.  First, the NONE cipher made more
> sense back when we didn't have AES-NI widely available, and you were
> seriously limited by it's performance.  Now we have both aes-gcm and
> chacha-poly which it's performance should be more than acceptable for
> today's uses (i.e. cipher performance is 2GB/sec+).
> 
> Second, I did some testing recently due to a thread on -net, and I
> found no significant (not run statistically though) difference in
> performance between in HEAD ssh and OpenSSH 7.1p1.  I started a wiki
> page to talk about this:
> https://wiki.freebsd.org/SSHPerf

Hmm, I see in this page max speed 20MB/sec. This is too small.
What is problem? With modern 40G NIC wanted speed about 20Gbit/s.
10Gbit/s at least.

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Tue, Nov 10, 2015 at 11:59:30PM -0800, John-Mark Gurney wrote:

> Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > On Wednesday, 11 November 2015, Bryan Drewery  wrote:
> > 
> > > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > > My vote is to remove the HPN patches.  First, the NONE cipher made more
> > > > sense back when we didn't have AES-NI widely available, and you were
> > > > seriously limited by it's performance.  Now we have both aes-gcm and
> > > > chacha-poly which it's performance should be more than acceptable for
> > > > today's uses (i.e. cipher performance is 2GB/sec+).
> > >
> > > AES-NI doesn't help the absurdity of double-encrypting when using scp or
> > > rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> > > for me.
> > 
> > I have to agree that there are cases when the NONE cipher makes sense, and
> > it is up to the end user to make sure they know what they are doing.
> > 
> > Personally I have used it at home to backup my old FreeBSD server (which
> > does not have AESNI) over a dedicated network connection to a backup server
> > using rsync/ssh. Since it was not possible for anyone else to be on that
> > local network, and the server was so old it didn't have AESNI and would
> > soon be retired, using the NONE cipher sped up the transfer significantly.
> 
> If you have a trusted network, why not just use nc?

I think you kidding:

- scp need only one command on initiator side and
  no additional setup on target. simple, well know.
- nc need additional work on target, need synchronization for file
  names with target, also need ssh to target for start, etc... Too
  complex.

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 10:18:08AM -0800, Bryan Drewery wrote:

> On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote:
> > On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
> > 
> >> Bryan Drewery <bdrew...@freebsd.org> writes:
> >>> Another thing that I did with the port was restore the tcpwrapper
> >>> support that upstream removed. Again, if we decide it is not worth
> >>> keeping in base I will remove it as default in the port.
> >>
> >> I want to keep tcpwrapper support - it is another reason why I still
> >> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
> >> less intrusive than HPN.
> > 
> > Can you explain what is problem?
> > I am see openssh in base and openssh in ports (more recent version)
> > with same functionaly patches.
> > You talk about trouble to upgrade. What is root?
> > openssh in base have different vendor and/or license?
> > Or something else?
> > 
> > PS: As I today know, kerberos heimdal is practicaly dead as opensource
> > project. Have FreeBSD planed switch to MIT Kerberos?
> > I am know about security/krb5.
> > 
> 
> IMHO the problem comes down to time. Patching an upstream project
> increases maintenance cost for upgrading it. Every patch adds up. When
> you become busy and don't have time to pay attention to every little
> change made in a release, hearing 'removed tcpwrappers support' or
> 'refactored the code  for libssh usage' makes it sound like 1 more
> thing you must deal with to upgrade that code base and more effort to
> validate that your patches are right. We obviously don't want to just
> drop in the latest code and throw it out there as broken. SSH is quite
> critical and we want to ensure our changes are still right, and that
> doing something like adding tcpwrappers back in won't introduce some
> security bug that upstream was coy about.

Some for as ports version?
Or ports version different?
Or port mantainer have more time (this is not to blame for DES)?
I am just don't know what is different between port ssh and base ssh.
We need ssh 6.x in base, not 7.x as in port (why?) and this is need
independed work on pathes?
I am missing somehow commonplace for others.

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 03:58:35PM -0800, Bryan Drewery wrote:

> > Some for as ports version?
> > Or ports version different?
> > Or port mantainer have more time (this is not to blame for DES)?
> > I am just don't know what is different between port ssh and base ssh.
> > We need ssh 6.x in base, not 7.x as in port (why?) and this is need
> > independed work on pathes?
> > I am missing somehow commonplace for others.
> > 
> 
> I am the ports maintainer. That was my opinion on why OpenSSH falls
> behind. There is no real difference between the base and port version
> except that the port version has some more optional patches, and is
> easier to push updates for through ports and packages, rather than an
> Errata through freebsd-update or a full release to get to the latest
> OpenSSH version.

This impact only to deploy, not to patch, right?
Or bugs found around NPH/NONE patches?

> There have been many times where the base version was more up-to-date
> than the port as well due to the lack of a maintainer or the previously
> mentioned patch blockers.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 01:32:27PM -0800, Bryan Drewery wrote:

> On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote:
> >  I would also like to remove the NONE cipher
> > patch, which is also available in the port (off by default, just like in
> > base).
> 
> Fun fact, it's been broken in the port for several months with no
> complaints. It was just reported and fixed upstream in the last day and
> I wrote in a similar fix in the port. That speaks a lot about its usage
> in the port currently.

I am try using NPH/NONE with base ssh and confused: don't see
performance rise, too complex to enable and too complex for use.

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 07:18:31PM +0100, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > Can you explain what is problem?
> 
> Radical suggestion: read the first email in the thread.

I am read and don't understund (you talk about trouble of maintaining
the HPN patches).
I see patched version in ports. This version maintaining.
What is problem? Differnt openssh? Quality of patches?
Different branches?
ports branch is worse (by some reaason) base branch?

> > PS: As I today know, kerberos heimdal is practicaly dead as opensource
> > project. Have FreeBSD planed switch to MIT Kerberos?  I am know about
> > security/krb5.
> 
> We switched from MIT to Heimdal at some point in the past for some
> reason I don't remember.  MIT and Heimdal are *not* interchangeable at

I think because MIT stop development in the past.

> the source or binary level, so switching back is not trivial.

I am know about this.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Tue, Nov 10, 2015 at 10:42:49AM +0100, Dag-Erling Smørgrav wrote:

> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
> 
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> that change significantly in every release.  Since they are not
> regularly updated, I have to choose between trying to resolve the
> conflicts myself (hoping I don't break anything) or waiting for them to
> catch up and then figuring out how to apply the new version.
> 
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option.  I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).

I am plan to use NONE and HPN for bulk transfer, but don't see
performance improvement, in both cases I see only 500Mbit/s.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: HTTPS on freebsd.org, git, reproducible builds

[Slawa Olhovchenkov]

On Sat, Sep 19, 2015 at 12:10:36AM +0200, Dag-Erling Smorgrav wrote:

> Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > freebsd-update builds is inreproducible by the freebsd-update-server bug[s].
> 
> freebsd-update will most likely be gone in 11.

What is planed for replacement?
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: HTTPS on freebsd.org, git, reproducible builds

[Slawa Olhovchenkov]

On Fri, Sep 18, 2015 at 02:49:01PM +0200, Dag-Erling Smorgrav wrote:

> grarpamp  writes:
> > Not to mention the irreproducible builds / pkgs / ISO's.
> 
> The base system build is 99% reproducible.  ISOs should be reproducible
> as well, modulo timestamps.

freebsd-update builds is inreproducible by the freebsd-update-server bug[s].

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-15:13.tcp

[Slawa Olhovchenkov]

On Thu, Jul 23, 2015 at 02:33:31PM -0700, Xin Li wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 (Bcc'ed some unnamed patch authors so they can correct me if I was wrong
 ).
 
 On 07/23/15 13:48, Slawa Olhovchenkov wrote:
  On Thu, Jul 23, 2015 at 12:29:57PM -0700, Xin Li wrote:
  
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
  
  On 07/22/15 06:18, Slawa Olhovchenkov wrote:
  On Wed, Jul 22, 2015 at 02:57:46AM +, FreeBSD Security 
  Advisories wrote:
  
  This is correspondent to kern/25986? Or kern/25986 is
  different bug?
  
  I think it's the same bug.
  
  I see patch in kern/25986 is different from SA. May be SA close not
  all issuses?
 
 Yes they are different, but I think that one and r284941 (MFC'ed to
 stable/10 as r285793) should have addressed all possible situations.

: When TCP socket goes to LAST_ACK state  remote host do not respone
: ACK forever, socket would stay at LAST_ACK forever and never be
: removed.

This situation too? Regardless of zero window condition?
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: FreeBSD Security Advisory FreeBSD-SA-15:13.tcp

[Slawa Olhovchenkov]

On Wed, Jul 22, 2015 at 02:57:46AM +, FreeBSD Security Advisories wrote:

This is correspondent to kern/25986?
Or kern/25986 is different bug?


 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 =
 FreeBSD-SA-15:13.tcpSecurity Advisory
   The FreeBSD Project
 
 Topic:  Resource exhaustion due to sessions stuck in LAST_ACK state
 
 Category:   core
 Module: inet
 Announced:  2015-07-21
 Credits:Lawrence Stewart (Netflix, Inc.),
 Jonathan Looney (Juniper SIRT)
 Affects:All supported versions of FreeBSD.
 Corrected:  2015-07-21 23:42:17 UTC (stable/10, 10.2-PRERELEASE)
 2015-07-21 23:42:17 UTC (stable/10, 10.2-BETA1-p1)
 2015-07-21 23:42:17 UTC (stable/10, 10.2-BETA2-p1)
 2015-07-21 23:42:56 UTC (releng/10.1, 10.1-RELEASE-p15)
 2015-07-21 23:42:20 UTC (stable/9, 9.3-STABLE)
 2015-07-21 23:42:56 UTC (releng/9.3, 9.3-RELEASE-p20)
 2015-07-21 23:42:20 UTC (stable/8, 8.4-STABLE)
 2015-07-21 23:42:56 UTC (releng/8.4, 8.4-RELEASE-p34)
 CVE Name:   CVE-2015-5358
 
 For general information regarding FreeBSD Security Advisories,
 including descriptions of the fields above, security branches, and the
 following sections, please visit URL:https://security.FreeBSD.org/.
 
 I.   Background
 
 The Transmission Control Protocol (TCP) of the TCP/IP protocol suite
 provides a connection-oriented, reliable, sequence-preserving data
 stream service.
 
 A socket enters the LAST_ACK state when the local process closes its socket
 after a FIN has already been received from the remote peer.  The socket
 will remain in the LAST_ACK state until the kernel has transmitted a FIN to
 the remote peer and the kernel has received an acknowledgement of that FIN
 from the remote peer, or all retransmits of the FIN have failed and the
 connection times out.
 
 II.  Problem Description
 
 TCP connections transitioning to the LAST_ACK state can become permanently
 stuck due to mishandling of protocol state in certain situations, which in
 turn can lead to accumulated consumption and eventual exhaustion of system
 resources, such as mbufs and sockets.
 
 III. Impact
 
 An attacker who can repeatedly establish TCP connections to a victim system
 (for instance, a Web server) could create many TCP connections that are
 stuck in LAST_ACK state and cause resource exhaustion, resulting in a
 denial of service condition.  This may also happen in normal operation
 where no intentional attack is conducted, but an attacker who can send
 specifically crafted packets can trigger this more reliably.
 
 IV.  Workaround
 
 No workaround is available, but systems that do not provide TCP based
 service to untrusted networks are not vulnerable.
 
 Note that the tcpdrop(8) utility can be used to purge connections which
 have become wedged.  For example, the following command can be used to
 generate commands that would drop all connections whose last rcvtime is
 more than 100s:
 
   netstat -nxp tcp | \
   awk '{ if (int($NF)  100) print tcpdrop  $4   $5 }'
 
 The system administrator can then run the generated script as a temporary
 measure.  Please refer to the tcpdump(8) manual page for additional
 information.
 
 V.   Solution
 
 Perform one of the following:
 
 1) Upgrade your vulnerable system to a supported FreeBSD stable or
 release / security branch (releng) dated after the correction date.
 
 2) To update your vulnerable system via a binary patch:
 
 Systems running a RELEASE version of FreeBSD on the i386 or amd64
 platforms can be updated via the freebsd-update(8) utility:
 
 # freebsd-update fetch
 # freebsd-update install
 
 3) To update your vulnerable system via a source code patch:
 
 The following patches have been verified to apply to the applicable
 FreeBSD release branches.
 
 a) Download the relevant patch from the location below, and verify the
 detached PGP signature using your PGP utility.
 
 [FreeBSD 10.1]
 # fetch https://security.FreeBSD.org/patches/SA-15:13/tcp.patch
 # fetch https://security.FreeBSD.org/patches/SA-15:13/tcp.patch.asc
 # gpg --verify tcp.patch.asc
 
 [FreeBSD 9.x and 8.x]
 # fetch https://security.FreeBSD.org/patches/SA-15:13/tcp-9.patch
 # fetch https://security.FreeBSD.org/patches/SA-15:13/tcp-9.patch.asc
 # gpg --verify tcp-9.patch.asc
 
 b) Apply the patch.  Execute the following commands as root:
 
 # cd /usr/src
 # patch  /path/to/patch
 
 c) Recompile your kernel as described in
 URL:https://www.FreeBSD.org/handbook/kernelconfig.html and reboot the
 system.
 
 VI.  Correction details
 
 The following list contains the correction revision numbers for each
 affected branch.
 
 Branch/path  Revision
 - 

Re: Forums.FreeBSD.org - SSL Issue?

[Slawa Olhovchenkov]

On Mon, May 18, 2015 at 08:42:54AM -0500, Mark Felder wrote:

  
Actually, that might be the reason -- Google search results. Perhaps
Google is also logging what protocols/ciphers your HTTPS has and is
using that in search rankings.
  
  You're seriously suggesting that the FreeBSD project should set security 
  policies to favour higher rankings from an advertising company?
  
 
 If people can't search Google and find results on the first page they're
 going to be very, very discouraged from even trying it out.
 
 I don't think I can provide any further information about what's going
 on here, but I hope that I've answered some questions about why this
 isn't such a terrible idea. Feel free to file a bug report if you would
 like this followed up by those who have control over these decisions.

Need higher rankings with https? Do https mirrors for google/bing.
Client can't use strong encription? Allow cleartext and weak
encription.
FreeBSD forum posts don't contains any sensitive information.
Be strict in what you send, but generous in what you receive
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Forums.FreeBSD.org - SSL Issue?

[Slawa Olhovchenkov]

On Mon, May 18, 2015 at 09:43:24AM +0200, pat...@patpro.net wrote:

 On 18 mai 2015, at 09:05, Ian Smith smi...@nimnet.asn.au wrote:
 
  
  Actually, that might be the reason -- Google search results. Perhaps
  Google is also logging what protocols/ciphers your HTTPS has and is
  using that in search rankings.
  
  You're seriously suggesting that the FreeBSD project should set security 
  policies to favour higher rankings from an advertising company?
 
 
 There's a bigger picture. Google is promoting strong security. Using web 
 sites HTTPS details (proto, ciphers, certificate trustworthiness...) as 
 ranking parameter is an incentive for admin to switch to better protocol and 
 stronger cipher suits ( more expensive certificates).
 Their next step, currently ongoing in fact, is to limit or even remove 
 browser confidence in older protocol/ciphers, so that users would be deterred 
 from visiting those web sites. Domain Validated certificates are probably a 
 target to be shot dead in few years too.
 
 As an admin I find it to be a pain in the *** to constantly have to deal with 
 latest Google vision, but as a user I think they are right because that's 
 the way to go for promoting strong crypto.

As user I am don't need crypto, strong or weak.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Logging TCP anomalies

[Slawa Olhovchenkov]

On Mon, Apr 27, 2015 at 03:12:43PM -0700, Ronald F. Guilmette wrote:

 
 In message a83fb715-936e-4a43-ae2d-e76c32d0f...@mac.com, 
 Charles Swiger cswi...@mac.com wrote:
 
 On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette r...@tristatelogic.com 
 wrot
 e:
 ...
  and/or whether FreeBSD provides any options which,
  for example, might automagically trigger a close of the relevant TCP
  connection when and if such an event is detected.  (Connection close
  seems to me to be one possible mitigation strategy, even if it might
  be viewed as rather ham-fisted by some.)
 
 You need to be able to distinguish normal dup packets
 
 Yes.
 
 As I understand it, (verbatim) duplicate packets can sometimes arrive at
 an endpoint due simply to network anomalies.  However as I understand it,
 those will typically have identical lengths and payloads.  If I read that
 news article correctly, then the spoofed packets at issue will have the
 same sequence numbers as legit ones, but different lengths and/or payloads.

different lengths is legitime -- in case of sender resend-packets and
reduce packet sizes (for example from differen interface with
different MTU).

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: ftpd don't record login in utmpx

[Slawa Olhovchenkov]

On Tue, Mar 31, 2015 at 10:09:00AM +0200, Willem Jan Withagen wrote:

 On 31-3-2015 05:44, Slawa Olhovchenkov wrote:
  On Mon, Mar 30, 2015 at 08:08:49PM -0400, Lowell Gilbert wrote:
 
  Slawa Olhovchenkov s...@zxy.spb.ru writes:
 
  ftpd from FreeBSD-10 and up don't record ftp logins to utmpx database
  (for case of chrooted login).
  This is lack security information.
  I found this is done by r202209 and r202604.
  I can't understand reason of this.
  Can somebody explain?
 
  Having a jail log into the base system is a security issue in the
  making. Can't you do this in a safer way by doing remote logging to the
  base system rather than having the jail hold on to a file handle that
  belongs outside the jail?
 
  Jail? Why I you talk about jail?
 
  It's certainly possible to maintain these kinds of capabilities, but
  you would have to convince code reviewers that the same results can't be
  achieved some other way that's easier to secure.
 
 I might have just too many miles on the clock already
 
 It used to liek this: to be able to do anything usefull in a chroot, 
 you'd rebuild those parts of the system tree that you need in under the 
 chrootdir.
 Eg. including ls(1) and all the libs it needed to function in ftpd.
 Some for apaches that ran chrooted, you'd carry/duplicate all you needed 
 into the chroot env
 
 So in this case you probably need
   ${CHROOTDIR/var/log
 and create the database there.

I have many ftp acconts, than need be isolated by ftp.
I need united database about login and logout.
FreeBSD 1.x-9.x do this.
Why this removed in 10.x?
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: ftpd don't record login in utmpx

[Slawa Olhovchenkov]

On Tue, Mar 31, 2015 at 12:28:04PM +0200, Willem Jan Withagen wrote:

  Slawa,
 
  I can't tell you that, but it is in r202209. And you can ask the one
  that removed it (ed@). :)
  Like r202209 says 5 years ago:
 Maybe we can address this in the future if it turns out to be a
 real issue.
 
  What about issue talk?
  Opened file outside chroot? /dev/null and /var/run/logpriv still opened.
  Disabling logging for chrooted accounts? Realy?!
 
 Read the submit message!? The reason is there, nothing with security as 
 I read it, but it just did not fit into the way the new lib for wtmp 
 worked/works.

I read it. And I don't understund it. May be I don't know somewere.
Or missed. Can you explain?

 Clearly you do not agree, but you are rather late to the party.
 
 Could be that in the mean time code has been added to wtmp, and now you 
 can do it from inside a chroot? Perhaps ask ed@ of on hackers@??

First I am ask security@.
Logging login and logout -- security task.

  Hasn't been an issue uptill now, it seems.
 
  But then there  are many flavours of FTP server out there ATM, so freely
  quoted from Andy Tannenbaum:
 If you don't like this version, get another one.
 
  Now I only see removing old and working functionality w/o reassonable
 
 Well that is only in your eyes. wtmp moved (on) to a different way of 
 storing the data. At that point in time nobody had a problem with that. 
 And in 5 years you are the first one to be vocal about it.

All others still using old version?

  Or write a script that actually unites the output from either the
  database and/or last(8).
 
  You kidding.
  For this I need rearange ALL ftp acconts. Change permissions. Create
  hieararhie. Learn users.
 
 Well perhaps one of the other flavours of FTPDs suits your need better.

I don't ask what I need do.
I just ask why switch off logging.
What issues may be happen?
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: ftpd don't record login in utmpx

[Slawa Olhovchenkov]

On Tue, Mar 31, 2015 at 03:15:45PM +0200, Willem Jan Withagen wrote:

 On 31-3-2015 15:00, Slawa Olhovchenkov wrote:
 
  Check:
  man utempter_add_record
 
  If you want the old behaviour, you have to dig into the code, and DIY.
  
  I understund, thanks.
  
 
  Bluntly put: I don't think anybody is going to fix YOUR problem. If only
  because in 5 years time nobody had an issue with it.
  
  Now I see root of problem.
  I can choose what do: patch ftpd, do nothing or something else.
 
 Sort of sorry, but yes.
 
 And then those are the 3 options with every piece of open source
 software. Whereas with closed software, option 1 would be a no-go.

I know what is open source software.
I know what different with closed software.
I am don't ask about this.
And I am don't ask what I need do.
I just ask about cause of behaviors changed -- commit messages not
cleary explain this.
Thanks again, you cleary explain root cause.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

ftpd don't record login in utmpx

[Slawa Olhovchenkov]

ftpd from FreeBSD-10 and up don't record ftp logins to utmpx database
(for case of chrooted login).
This is lack security information.
I found this is done by r202209 and r202604.
I can't understand reason of this.
Can somebody explain?
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: ftpd don't record login in utmpx

[Slawa Olhovchenkov]

On Mon, Mar 30, 2015 at 08:08:49PM -0400, Lowell Gilbert wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru writes:
 
  ftpd from FreeBSD-10 and up don't record ftp logins to utmpx database
  (for case of chrooted login).
  This is lack security information.
  I found this is done by r202209 and r202604.
  I can't understand reason of this.
  Can somebody explain?
 
 Having a jail log into the base system is a security issue in the
 making. Can't you do this in a safer way by doing remote logging to the
 base system rather than having the jail hold on to a file handle that
 belongs outside the jail?

Jail? Why I you talk about jail?

 It's certainly possible to maintain these kinds of capabilities, but
 you would have to convince code reviewers that the same results can't be
 achieved some other way that's easier to secure.

Can you explain some more?
A im lost point.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: FreeBSD Security Advisory FreeBSD-SA-15:05.bind

[Slawa Olhovchenkov]

On Thu, Mar 05, 2015 at 12:53:35PM +0100, Dag-Erling Smorgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru writes:
  I see same message for may setup (track -STABLE) for base component.
 
 You can't run freebsd-update on a system that tracks -STABLE (i.e. is
 built from source).

No, I don't run freebsd-update on a system that tracks -STABLE.
I run freebsd-update FOR track -STABLE (i have private
freebsd-update-server and build update to -STABLE for freebsd-update).
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: FreeBSD Security Advisory FreeBSD-SA-15:05.bind

[Slawa Olhovchenkov]

On Tue, Feb 24, 2015 at 11:40:44PM -0800, Xin Li wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 
 
 On 2/24/15 23:36, Bartek Rutkowski wrote:
  Seems like freebsd-update is throwing some error:
  
  root@04-dev:~ # freebsd-update install Installing
  updates...install: ///usr/src/crypto/openssl/util/mkbuildinf.pl: No
  such file or directory done. root@04-dev:~ # uname -a FreeBSD
  04-dev 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0: Tue Jan 27 
  08:55:07 UTC 2015 
  r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
  amd64
  
  Anything to worry about?
 
 No.
 
 This is a known issue with freebsd-update, which is confused by added
 (source) files.

Do you planed to fix it?
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: bash velnerability

[Slawa Olhovchenkov]

On Thu, Sep 25, 2014 at 03:35:55PM -0400, Chris Nehren wrote:

 On Thu, Sep 25, 2014 at 11:57:38 -0500, Bryan Drewery wrote:
  1. Do not ever link /bin/sh to bash. This is why it is such a big
  problem on Linux, as system(3) will run bash by default from CGI.
 
 I would think that this would cause other, more fundamental,
 issues.  FreeBSD's system don't expect /bin/sh to be bash,
 and I wouldn't be surprised if they break for whatever reason.
 
  2. Web/CGI users should have shell of /sbin/nologin.
  3. Don't write CGI in shell script / Stop using CGI :)
  4. httpd/CGId should never run as root, nor apache. Sandbox each
  application into its own user.
 
 And its own jail.  Jails with ZFS are dirt cheap.

For goodness of jail with ZFS we need fixing unionfs and devfs.

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

ftp login accounting in 10.x

[Slawa Olhovchenkov]

In 10.x branch ftpd don't record successful login into login data base
(/var/log/utx.log).

For examle, in 9.x and earlier:

slwftpd localhost  Thu Aug 14 19:47 - 19:47 (00:00)

Now I don't have such records.

What reasson for remove this functionality ?
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

(sshd), uid 0: exited on signal 11

[Slawa Olhovchenkov]

FreeBSD 10.0-STABLE #5 r265949M: Tue May 13 19:52:37 MSK 2014

Jun 16 14:06:07 srv3 kernel: pid 95261 (sshd), uid 0: exited on signal 11
Jun 24 06:03:25 srv3 kernel: pid 59497 (sshd), uid 0: exited on signal 11
Jun 24 06:03:31 srv3 kernel: pid 59500 (sshd), uid 0: exited on signal 11
Jun 24 06:04:15 srv3 kernel: pid 59535 (sshd), uid 0: exited on signal 11
Jun 24 06:05:56 srv3 kernel: pid 59582 (sshd), uid 0: exited on signal 11
Jun 24 06:09:50 srv3 kernel: pid 59641 (sshd), uid 0: exited on signal 11
Jun 24 06:13:21 srv3 kernel: pid 59721 (sshd), uid 0: exited on signal 11
Jun 24 06:18:47 srv3 kernel: pid 59808 (sshd), uid 0: exited on signal 11
Jun 24 06:22:48 srv3 kernel: pid 59878 (sshd), uid 0: exited on signal 11
Jul  1 15:53:53 srv3 kernel: pid 19659 (sshd), uid 0: exited on signal 11
Jul  1 15:55:33 srv3 kernel: pid 19747 (sshd), uid 0: exited on signal 11
Jul  1 15:57:25 srv3 kernel: pid 19838 (sshd), uid 0: exited on signal 11
Jul  1 16:03:10 srv3 kernel: pid 20156 (sshd), uid 0: exited on signal 11
Jul  1 16:07:16 srv3 kernel: pid 20330 (sshd), uid 0: exited on signal 11
Jul  2 14:41:15 srv3 kernel: pid 42669 (sshd), uid 0: exited on signal 11
Jul  2 14:41:58 srv3 kernel: pid 42696 (sshd), uid 0: exited on signal 11
Jul  2 14:42:12 srv3 kernel: pid 42712 (sshd), uid 0: exited on signal 11
Jul  2 14:43:12 srv3 kernel: pid 42758 (sshd), uid 0: exited on signal 11
Jul  2 14:43:15 srv3 kernel: pid 42763 (sshd), uid 0: exited on signal 11
Jul  2 14:43:19 srv3 kernel: pid 42766 (sshd), uid 0: exited on signal 11
Jul  2 14:43:49 srv3 kernel: pid 42793 (sshd), uid 0: exited on signal 11
Jul  2 14:43:59 srv3 kernel: pid 42803 (sshd), uid 0: exited on signal 11
Jul  2 14:45:17 srv3 kernel: pid 42891 (sshd), uid 0: exited on signal 11
Jul  2 14:45:31 srv3 kernel: pid 42906 (sshd), uid 0: exited on signal 11
Jul  2 14:46:04 srv3 kernel: pid 42944 (sshd), uid 0: exited on signal 11
Jul  2 14:46:07 srv3 kernel: pid 42947 (sshd), uid 0: exited on signal 11
Jul  2 14:46:26 srv3 kernel: pid 42965 (sshd), uid 0: exited on signal 11
Jul  2 14:46:29 srv3 kernel: pid 42968 (sshd), uid 0: exited on signal 11
Jul  2 14:49:19 srv3 kernel: pid 43128 (sshd), uid 0: exited on signal 11
Jul  2 14:49:55 srv3 kernel: pid 43164 (sshd), uid 0: exited on signal 11
Jul  2 14:52:50 srv3 kernel: pid 43296 (sshd), uid 0: exited on signal 11
Jul  2 14:53:22 srv3 kernel: pid 43317 (sshd), uid 0: exited on signal 11
Jul  2 14:55:00 srv3 kernel: pid 43397 (sshd), uid 0: exited on signal 11
Jul  2 14:55:20 srv3 kernel: pid 43428 (sshd), uid 0: exited on signal 11
Jul  2 14:56:21 srv3 kernel: pid 43473 (sshd), uid 0: exited on signal 11
Jul  2 14:56:32 srv3 kernel: pid 43482 (sshd), uid 0: exited on signal 11
Jul  2 15:01:47 srv3 kernel: pid 43732 (sshd), uid 0: exited on signal 11
Jul  2 15:04:01 srv3 kernel: pid 43836 (sshd), uid 0: exited on signal 11
Jul  2 15:06:34 srv3 kernel: pid 43937 (sshd), uid 0: exited on signal 11
Jul  2 15:09:37 srv3 kernel: pid 44083 (sshd), uid 0: exited on signal 11
Jul  3 11:43:32 srv3 kernel: pid 2 (sshd), uid 0: exited on signal 11
Jul  3 11:44:23 srv3 kernel: pid 66709 (sshd), uid 0: exited on signal 11
Jul  3 11:45:20 srv3 kernel: pid 66747 (sshd), uid 0: exited on signal 11
Jul  3 11:45:47 srv3 kernel: pid 66775 (sshd), uid 0: exited on signal 11

What is this? New exploit in sshd?
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

openssh gcmrekey

[Slawa Olhovchenkov]

http://www.openssh.com/txt/gcmrekey.adv

2. Affected configurations
  OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL
  that supports AES-GCM.

  
=

FreeBSD affected? 
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

On Fri, Sep 06, 2013 at 09:39:33AM +0200, Dag-Erling Sm??rgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru 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` from root to this account also refused, with message 'pam_acct_mgmt:
error in service module'. Creatin ~/.login_conf resolve this.

May be this is PAM issue? Or libutil?

 portable mailing list (openssh-unix-...@mindrot.org)

My previos message to this list silently lost.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

On Tue, Sep 03, 2013 at 09:51:35AM +0200, Dag-Erling Sm??rgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru 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 a conversation
 function, the event loop resumes until it receives an answer from the
 client.  This is why PAM needs to run in a separate thread or process.
 OpenSSH was not designed to be multi-threaded, and we can't be sure
 there won't be conflicts.

We can be sure if separate thread don't access same data as other
sshd, or while other sshd wait answer from separate thread. I don't
see parallel execution in separate thread.

 Another problem is that libpam loads shared objects (the modules) when
 it runs, which may result in conflicts as well - espcially with
 pam_ssh(8).

Can you explain this? How conflicts and what scenario use pam_ssh in sshd?

 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 application (in this case, sshd).

I think this is impossible, because credentials for pam_krb5 is simple
pointer to internal blob's with unknown size, structure and links with
other elements.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

On Tue, Sep 03, 2013 at 11:31:09AM +0200, Dag-Erling Sm??rgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru writes:
  Dag-Erling Sm??rgrav d...@des.no 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 application (in this case, sshd).
  I think this is impossible, because credentials for pam_krb5 is simple
  pointer to internal blob's with unknown size, structure and links with
  other elements.
 
 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 resolved situation with PAM credentials
(Kerberos credentials in may case)?
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

On Tue, Sep 03, 2013 at 11:38:48AM +0200, Dag-Erling Sm??rgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru writes:
  Dag-Erling Sm??rgrav d...@des.no 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 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 password only once,
at login time and use this credentials to login to other host and use
Kerberosed NFS w/o entering password.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

On Tue, Sep 03, 2013 at 01:27:04PM +0200, Dag-Erling Sm??rgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru writes:
  Dag-Erling Sm??rgrav d...@des.no writes:
   Slawa Olhovchenkov s...@zxy.spb.ru 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 password only once,
  at login time and use this credentials to login to other host and use
  Kerberosed NFS w/o entering password.
 
 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 independent of the PAM session and the application.  The
 location of the permanent credential cache is exported to the
 application through the KRB5CCNAME environment variable.

Yes, but content of credential cache got at time pam_authenticate().
And this content (size, structure and links to other objects)
invisible outside PAM. Application (and authenticate daemon) can't be
extract this for transfer and (in general case) can't be know about
necessary acts (write to file? what file? set enviroment?) -- all this
activity do internals by PAM modules -- one bu pam_krb5, other by
pam_opie and pam_unix. Also, authenticate daemon (in case authenticate
daemon call pam_setcred) can't be know what need to transfer (chaneged UID?
new enviroment? deleted enviroment?) 
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

On Tue, Sep 03, 2013 at 03:23:48PM +0200, Dag-Erling Sm??rgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru writes:
  Dag-Erling Sm??rgrav d...@des.no 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 independent of the PAM session and the application.  The
   location of the permanent credential cache is exported to the
   application through the KRB5CCNAME environment variable.
  Yes, but content of credential cache got at time pam_authenticate().
 
 Did you read *anything* that I wrote?

I read. May be I bad writing, sorry for my english.

 The pam_krb5 module obtains your credentials and stores them in a
 persistent cache which is *independent* of the module and of the
 application that called it.  The *only* thing it needs to communicate to
 the application is the value of KRB5CCNAME.  If this wasn't the case,
 pam_krb5 wouldn't work with *any* applications whatsoever, not just
 sshd.

Application don't know about KRB5CCNAME (in general case). And
authenticate daemon don't know about KRB5CCNAME. How the demon can
learn about need to transfer KRB5CCNAME to application?

If called from application pam_krb5 change application environment or
context and application don't worry about changes. All be done by PAM
modules.

  Also, authenticate daemon (in case authenticate daemon call
  pam_setcred) can't be know what need to transfer (chaneged UID?  new
  enviroment? deleted enviroment?)
 
 Actually, sshd already does most of this by farming PAM out to a child
 process.
 
 DES
 -- 
 Dag-Erling Sm??rgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

On Mon, Sep 02, 2013 at 07:36:57PM +0200, Dag-Erling Sm??rgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru 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 OpenSSH is not thread-safe.  The threads are only
 partially synchronized, and service modules may for instance call
 getpwent() and thereby clobber global state which OpenSSH relies on.

As I understand interaction between sshd and pam subsystem occur next:

1. sshd need pam auth
2. call sshpam_init_ctx
3. sshpam_init_ctx do sshpam_init
4. sshpam_init_ctx for non-blocking processing do
   pthread_create(sshpam_thread) (emulated by fork).
5. in child process sshpam_thread do pam_authenticate and store cred.
6. child process terminated by sshpam_free_ctx
7. sshd do pam_setcred for context from [2] (and lost cred in child
   process).
8. sshd fork less-priveleged child
9. child terminated
10. pam session closed.


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

W/o thread we need constanly run 3 sshd: unpriveleged, priveleged
worked witch pam and master process.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

On Fri, Aug 30, 2013 at 09:44:54AM +0200, Dag-Erling Sm??rgrav wrote:

 Slawa Olhovchenkov s...@zxy.spb.ru 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_authenticate and can't work corretly (can't create
  /tmp/krb5cc_, can't set envirompent KRB5CCNAME and so).
 
 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'.

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

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 s...@zxy.spb.ru 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_authenticate and can't work corretly (can't create
   /tmp/krb5cc_, can't set envirompent KRB5CCNAME and so).
  
  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 privilege separation, this is because PAM
authentication use pthread emulation throw fork().
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

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_setcred() required information from
 pam_sm_authenticate and can't work corretly (can't create
 /tmp/krb5cc_, can't set envirompent KRB5CCNAME and so).
 
 In logs/debugs this is as 
 
 openpam_dispatch(): pam_krb5.so: pam_sm_setcred(): failed to retrieve user 
 credentials

As I see, similar bug open in upstream from 2003: 
https://bugzilla.mindrot.org/show_bug.cgi?id=688
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

OpenSSH, PAM and kerberos

[Slawa Olhovchenkov]

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 (can't create
/tmp/krb5cc_, can't set envirompent KRB5CCNAME and so).

In logs/debugs this is as 

openpam_dispatch(): pam_krb5.so: pam_sm_setcred(): failed to retrieve user 
credentials

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Allowing tmpfs to be mounted in jail?

[Slawa Olhovchenkov]

On Fri, Aug 23, 2013 at 12:37:32AM +0300, Konstantin Belousov wrote:

 On Thu, Aug 22, 2013 at 12:15:29PM -0700, Xin Li wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA512
  
  Hi,
  
  Do anybody have concerns if I would commit this?
  
  Index: sys/fs/tmpfs/tmpfs_vfsops.c
  ===
  - --- sys/fs/tmpfs/tmpfs_vfsops.c   (revision 254663)
  +++ sys/fs/tmpfs/tmpfs_vfsops.c (working copy)
  @@ -420,4 +420,4 @@ struct vfsops tmpfs_vfsops = {
  .vfs_statfs =   tmpfs_statfs,
  .vfs_fhtovp =   tmpfs_fhtovp,
   };
  - -VFS_SET(tmpfs_vfsops, tmpfs, 0);
  +VFS_SET(tmpfs_vfsops, tmpfs, VFCF_JAIL);
  
 
 Unrestricted tmpfs mounts can easily consume all available memory,
 making the host unusable.  But the change is probably fine, since
 we have global 'disable mount from the jail' flag.

tmpfs in jail must use memory limit from rctl memoryuse, I think.

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org