Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Dec 2017 12:14:55 -0800
From:      "Chris H" <portmaster@BSDforge.com>
To:        "Kurt Jaeger" <lists@opsec.eu>
Cc:        <freebsd-ports@freebsd.org>
Subject:   Re: Procmail Vulnerabilities check
Message-ID:  <5fd8da61ee9e3a818fbb43f5e461d054@udns.ultimatedns.net>
In-Reply-To: <20171211183649.GB2827@home.opsec.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Dec 2017 19:36:49 +0100 "Kurt Jaeger" <lists@opsec=2Eeu> said

> Hi!
>=20
> > if the majority of people install their systems via packages, that make=
s for
> > a fairly common FreeBSD base across all users=2E
>=20
> Why would a system installed via packaged be more homogenous than
> one installed as base, and updated via freebsd-update ? I don't
> understand this -- can you elaborate ?
OK=2E I'll try=2E I'm afraid I sort of went on a Jag, and didn't really make a =
good
point -- if *any* point=2E Sorry=2E
But to the point, and sorry for the (additional) deviation;
If I have a user base that shares a near identical install=2E I am far closer
to finding/having a pattern I can work with to *exploit*, as an evil hacker=
=2E
So here's the thing; working from the history of Linux, and for that matter=
,
even MS products=2E=2E=2E someone discovers an exploit in FreeBSD, or some compon=
ent
common to FreeBSD=2E I can take down a *much* greater number of users, now th=
at
the (larger) portion of FreeBSD' user base share such a common install base=
 --
applications(ports)/kernel et al; are pretty much all the same for *everyon=
e*
because of the introduction of pkg(8)=2E
Yes=2E But what's the difference if they made everything from ports(7)?
IMHO, and experience, users confronted with options during build time, are
*more* likely to actually *choose* options that better suite their use/need=
s=2E
But using packages is easier, and so if in the end everything just *works*=2E
There's little incentive to use that scary "make" thing, and have to learn
all those intimidating things associated with the ports system=2E
Well, FLAVORS should solve all that=2E Wouldn't it?
That *does* seem like a strong argument, and while I applaud all the effort=
s,
and those that are responsible for those efforts=2E The jury is still out=2E
FLAVORS has yet to *fully* arrive=2E So it's just too early to say for sure=2E
But I would agree that it *should*=2E
When I look back at all the security threats that Linux had to deal with
(even now), and how the ultimate argument was so often; use *BSD, it's a
much more secure OS by design=2E Which was true=2E Linux was/is always installe=
d
in packages, or by what ever moniker they use for them=2E With that, and thei=
r
choice of kernel arrangement=2E They were left as easier targets than the BSD
family of operating systems=2E Now looking at the increasingly narrowing of
differences between the two=2E I can't help but think that the threat vector
gap is *also* narrowing=2E

>=20
> > In closing, and more to the point regarding Sendmail; Sendmail has a ne=
arly
> > impeccable security record in at the last decade=2E It provides a *secure=
*,
> > more powerful, and more flexible MX on the cheap=2E I see little reason t=
o
> > consider it an attack vector=2E Which makes *security*, and it's related
> > maintenance a pretty poor argument, for it's removal=2E
>=20
> The argument is: The update process for base is more complex
> than for packages, and we've come a long way to have a very
> nice pkg-system, in general=2E The mid-term plan is thus to package base, t=
oo=2E
>=20
> Packaging base means sensible packages have to be defined, and
> sendmail suits a package very well=2E
Indeed it *does*, and *should* be a package installed *along* with $BASE=2E
That's my only argument there=2E :-)

Thanks for your thoughtful reply, Kurt!

--Chris
>=20
> --=20
> pi@opsec=2Eeu            +49 171 3101372                         3 years to=
 go
> !





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5fd8da61ee9e3a818fbb43f5e461d054>