Bug#727708: upstart (security) bugs

2013-12-03 Thread Steve Langasek 
On Tue, Dec 03, 2013 at 07:42:39PM +0100, Josselin Mouette wrote:

>  Message transféré 
> De: Jef Spaleta 
> À: Josselin Mouette 
> Sujet: Re: FYI: for the systemd security debate.
> Date: Mon, 2 Dec 2013 23:39:59 -0900
> 
> Evening,
> 
> So looking deeper into the upstart bug tracker. I just don't think
> people have bothered filing CVE requests against upstart at
> all..ever...for anything..even though there have clearly been some
> SERIOUS system security impacting bugs that have reached users in
> Ubuntu releases.

> here's an example of a file descriptor leak in upstart, with
> exploit code which could cause a service level DoS be chewing up
> all available file descriptors.  Canonical did an internal
> review...didn't request a cve or external impact accessment..and
> decided it was a normal bug fix.
> https://bugs.launchpad.net/upstart/+bug/83099
> The severity of this is basically the same level of the journald
> related CVE-2013-4393

It does appear to me that this bug should have been treated as a security
bug, but for some reason the developers who did the analysis at the time
felt that "the potential impact on [the affected Ubuntu release] is
negligible".  I don't know why, but all other things being equal, I would
assume that they're right that it wasn't exploitable in the release in
question and therefore didn't warrant a CVE.

This bug is also six years old.  I don't think it makes sense to judge any
project by how bugs were being handled 6 years ago.

> here is an example of a simple programming mistake that lead to a
> user space upstart job causing the pid 1 process to fall over and
> die.  Fixed in an update...  no CVE requested.
> https://bugs.launchpad.net/upstart/+bug/807293
> This is pretty severe. unprivledge user job taking down pid 1
> entirely.

It is a severe error, but it was only exploitable in a configuration that no
one ever shipped.  RHEL6 shipped with upstart 0.6.5, which predated the
changes upstream to allow user sessions (first introduced in release 0.9.0).
SuSE shipped upstart 0.3.9.  Ubuntu shipped 0.9.7, which did have the bug,
but with a dbus configuration that prohibited non-root access to the
problematic calls.  As there were no known downstreams affected by this
issue in practice, we did not consider this to warrant a CVE.

> Here's an example of a FULL ROOT ACCESS exploit from console. 
> Fixed release in Ubuntu with an update...  no CVE. 
> https://bugs.launchpad.net/upstart/+bug/63852

This bug only affected a pre-release version of Ubuntu... seven years ago. 
The bug is marked as being present only in the Ubuntu-specific packaging. 
We are generally not in the habit of requesting CVEs for prerelease-only
issues.

> I do not share his accusations of bad faith; after all, Ubuntu being
> both upstream and downstream for this piece of software, it is
> understandable that some developers focus on fixing bugs quickly rather
> than asking for CVE numbers. However, I find this habit of not
> registering CVEs worrying for two reasons.

>  1. It is the sign of insufficient security awareness from some
> developers. Even if Debian were to adopt upstart and make these
> habits change, it is plausible that some developers would not
> take appropriate measures, should new bugs be found. 
>  2. If we are to consider past security issues (which again, is
> normal in any software package, even well designed) as a metric
> for the current security status of available init systems, I am
> afraid we are lacking data on upstart.

A careful analysis of the presented bugs does not support this conclusion.
If a security-relevant bug had turned up in upstart that affected a release
that was being used downstream, we would certainly take that seriously and
follow all the relevant procedures (CVE request, cross-vendor notification,
etc.)  In practice, TTBOMK this has never been the case.

Certainly, any bug that had warranted a security update in an Ubuntu stable
release would have received a CVE assignment.  There haven't been any of
those.

> I don’t know whether Jef’s list is complete. It would be nice if someone
> had the time to dig into old upstart bugs to see which ones would have
> mandated a security label.

I think that would be a great waste of the tech committee's time and
attention.  When you start digging for security issues in prerelease code
that doesn't /warrant/ a CVE, this is no longer an apples-to-apples
comparison.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ub

Re: Bug#727708: systemd (security) bugs

2013-12-03 Thread Tollef Fog Heen 
]] Don Armstrong 

> Right; I think we definitely should integrate many of the components
> that are being developed. I'm just concerned that the
> component<->systemd interface is still changing, and because the
> codebase is integrated, there's less of a requirement to communicate and
> document what that interface is than there would be if they were
> distinct projects.

If it's covered by the interface stability promise, it's stable.  If
it's marked as an internal interface, well, then it's an internal
interface.  I believe interfaces will over time move towards being under
the stability interface promise.  Which and how fast is something that
can influenced based on what's needed.

> This concern isn't very strong, but it was piqued when udev development
> was brought into systemd; I'm still not certain why that was necessary.

Circular build deps was the initial reason cited upstream.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2txep7hw0@rahvafeir.err.no

Bug#727708: systemd (security) bugs (was: init system question)

2013-12-03 Thread Moritz Muehlenhoff 
On Sun, Dec 01, 2013 at 12:11:11PM -0600, Steve Langasek wrote:
> > More review and more usage will lead to more bugs being found, we should
> > rather applaud Red Hat for investing resources and be diligent. After all
> > Red Hat is the only distro staffing a proactive product security team
> > (from which everyone is profiting outside of RH as well). I don't consider
> > the lack of reported security issues for the contenders as a credible 
> > indication of them being more secure.
> 
> Red Hat shipped upstart as their init system in RHEL 6.  This did not result
> in any CVEs being issued for upstart.  What conclusions should we draw from
> this?

None. The RH Product Security Team didn't exist back then (founded 1.5 years 
ago).

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131203210029.ga24...@inutil.org

Bug#727708: upstart (security) bugs

2013-12-03 Thread Bdale Garbee 
Josselin Mouette  writes:

> a friend of mine mentioned (not in a pub, but in a serious discussion
> about systemd & upstart) that he looked into upstart bugs more closely

Thanks to Jef for this work, the results and his comparison of some bugs
to systemd CVEs is quite interesting.

> However, I find this habit of not registering CVEs worrying...

Your point is taken.  I think no matter what decision we make here,
there will always be some bugs that fall on either side of the "to CVE
or not to CVE" line that we could choose to quibble about in hindsight.

> It would be nice if someone had the time to dig into old upstart bugs
> to see which ones would have mandated a security label.

Perhaps.  I think the point has been made, however, so spending more
time on this might not really add anything new to the discussion.  What
we really care about is the current quality of the code and the
probability of issues in the future, after all, not so much what's in
the past.

Bdale


pgpIBnWXoSAAO.pgp
Description: PGP signature

Re: Bug#727708: systemd (security) bugs

2013-12-03 Thread Don Armstrong 
On Tue, 03 Dec 2013, Tollef Fog Heen wrote:
> ]] Russ Allbery 
> > Don Armstrong  writes:
> > 
> > > Projects which have multiple components, each of which has
> > > different security/interface surfaces without stable defined
> > > interfaces, can lead to problems when one set of developers
> > > doesn't understand the security implications of the parts that
> > > they do not work on.
> > 
> > It's unclear to me that this is a correct characterization of
> > systemd. Do the separate components of systemd not have stable,
> > defined interfaces? I know they largely don't have other
> > implementations, but that's not the same thing.
> 
> http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
> 
> has a table with the various interfaces and their status.

This was useful; thanks for linking to this.

[...]

> > If the interfaces for those supplemental components are actually
> > unstable, that's going to pose problems all around, but I'm not sure
> > how directly relevant to this discussion that is since we're going
> > to have to deal with those components *anyway*.

Right; I think we definitely should integrate many of the components
that are being developed. I'm just concerned that the
component<->systemd interface is still changing, and because the
codebase is integrated, there's less of a requirement to communicate and
document what that interface is than there would be if they were
distinct projects.

This concern isn't very strong, but it was piqued when udev development
was brought into systemd; I'm still not certain why that was necessary.

-- 
Don Armstrong  http://www.donarmstrong.com

It is easier to build strong children than to repair broken men.
 -- Frederick Douglass


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131203191617.gr4...@rzlab.ucr.edu

Bug#727708: upstart (security) bugs

2013-12-03 Thread Ian Jackson 
Josselin Mouette writes ("Bug#727708: upstart (security) bugs"):
> I do not share his accusations of bad faith; [...]

It is not appropriate to post these accusations of bad faith to Debian
forums, even if you are quoting an email from someone else, and
whether you add a rider of this kind or not.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21150.11505.314994.928...@chiark.greenend.org.uk

Bug#727708: upstart (security) bugs

2013-12-03 Thread Josselin Mouette 
Hi,

a friend of mine mentioned (not in a pub, but in a serious discussion
about systemd & upstart) that he looked into upstart bugs more closely,
and found an alarming trend of security bugs that were not flagged as
such. 

I do not share his accusations of bad faith; after all, Ubuntu being
both upstream and downstream for this piece of software, it is
understandable that some developers focus on fixing bugs quickly rather
than asking for CVE numbers. However, I find this habit of not
registering CVEs worrying for two reasons.

 1. It is the sign of insufficient security awareness from some
developers. Even if Debian were to adopt upstart and make these
habits change, it is plausible that some developers would not
take appropriate measures, should new bugs be found. 
 2. If we are to consider past security issues (which again, is
normal in any software package, even well designed) as a metric
for the current security status of available init systems, I am
afraid we are lacking data on upstart.

I don’t know whether Jef’s list is complete. It would be nice if someone
had the time to dig into old upstart bugs to see which ones would have
mandated a security label.


 Message transféré 
De: Jef Spaleta 
À: Josselin Mouette 
Sujet: Re: FYI: for the systemd security debate.
Date: Mon, 2 Dec 2013 23:39:59 -0900

Evening,

So looking deeper into the upstart bug tracker. I just don't think
people have bothered filing CVE requests against upstart at
all..ever...for anything..even though there have clearly been some
SERIOUS system security impacting bugs that have reached users in
Ubuntu releases.

here's an example of a file descriptor leak in upstart, with exploit
code which could cause a service level DoS be chewing up all available
file descriptors. Canonical did an internal review...didn't request a
cve or external impact accessment..and decided it was a normal bug
fix.
https://bugs.launchpad.net/upstart/+bug/83099
The severity of this is basically the same level of the journald
related CVE-2013-4393

here is an example of a simple programming mistake that lead to a user
space upstart job causing the pid 1 process to fall over and die.
Fixed in an update... no CVE requested.
https://bugs.launchpad.net/upstart/+bug/807293
This is pretty severe. unprivledge user job taking down pid 1 entirely.

Here's an example of a FULL ROOT ACCESS exploit from console.  Fixed
release in Ubuntu with an update... no CVE.
https://bugs.launchpad.net/upstart/+bug/63852

So here's the big problem with looking at CVEs.  Single distribution
solutions... like upstart...are much much less likely to use the CVE
system at all to register security issues.

You deep dive into upstart's bug tracker on launchpad, and your going
to keep finding more and more examples of classic security impact
bugs..just noone is actually labelling them as security impacters. The
worrisome thing here is that Canonical and the Ubuntu release
management have NOT felt the need to classify the problems as security
impactors. If  had a dog in the debian fight, I'd be very very tempted
to call the lack of CVEs on these past security issues bad faith...as
if Canonical was trying to purposely avoid calling attention to the
severity of these problems.  But I do love bug 63852...its a very
elegant backdoor on the console.


-jef


-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1386096159.24216.1509.camel@dsp0698014

Bug#727708: systemd code documentation

2013-12-03 Thread Russ Allbery 
Eugene Zhukov  writes:

> The frequency of comments sometimes reflects poor quality of code.  When
> you feel compelled to add a comment, consider rewriting the code to make
> it clearer.

That would indeed be a succinct statement of the other perspective on code
comments, which as mentioned in my original message is a perspective that
I understand but disagree with.  :)

The fact that this is disputed and to some degree a matter of style is a
large part of why I mentioned that I don't consider this difference
decisive.

That said, I really do recommend upstart as an example of a nicely-written
and readable code base, although that's partly because much of it is
written the way I would have written that code.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eh5tu8s5@windlord.stanford.edu

Bug#727708: systemd code documentation

2013-12-03 Thread Ian Jackson 
Eugene Zhukov writes ("Bug#727708: systemd code documentation"):
> The frequency of comments sometimes reflects poor quality of code.
> When you feel compelled to add a comment, consider rewriting the code
> to make it clearer.

Please can we avoid arguing about this particular bikeshed here.

Thanks are due to Russ for his research.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21149.63917.274637.615...@chiark.greenend.org.uk

Bug#727708: systemd code documentation

2013-12-03 Thread Eugene Zhukov 
Russ Allbery  writes:

> This documentation is really, really nice, but it's a bit different than
> what I was talking about.  I should be clear, though (and please also do
> mention this to Lennart): the user-facing and the integration
> documentation for systemd seems quite good. This is more the code-level,
> helping the programmer sort of documentation, which is a bit lower-level.

The frequency of comments sometimes reflects poor quality of code.
When you feel compelled to add a comment, consider rewriting the code
to make it clearer.

Just my two cents,
Eugene


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/capqgmflxbkyrdh0cxoyldf1qsz64nhzumyntkfu5fpsrwwj...@mail.gmail.com

Bug#727708: systemd (security) bugs (was: init system question)

2013-12-03 Thread Sergey B Kirpichev 
On Sun, Dec 01, 2013 at 09:50:49PM +, Ian Jackson wrote:
> If we were to adopt systemd as pid 1, which sections of the systemd
> source code would we probably want to adopt as well ?  Or to put it
> another way, which other existing programs would be obsoleted ?

Again, very good question.  And answer to this on the debate page is
very worrying, assuming that security concerns were unresolved yet.
(e.g.: CVE-2012-1101 or CVE-2013-4393 examples in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#583)

Personally, as maintainer of the monit package I have objections
against statement:
> Systemd’s service monitoring replaces most uses of daemontools,
> runit, monit, and maybe other similar packages.
This may be correct for daemontools/runit, but not for monit or any
other application-level utility ("if failed port 80 protocol http and
request ... then restart") for proactive monitoring (for example,
zabbix has similar functional).

But systemd can cause conflicts (this depends on the adopted
systemd's default configuration) and so, can create hard-to-debug problems here.

Another questionable statement:
> Most of these bugs have been found by the Red Hat Product security
> team conducting an audit of the code as part of its inclusion in
> their enterprise distribution. Therefore, systemd's security record
> cannot reasonably be compared with implementations that didn’t
> undergo similar audits.

Both upstart and sysvinit were part of RHEL.  Please explain
the difference.

PS:
And just a side note.  It's only my own impression,
that there is too many hate/love around systemd?
Personally, during conversation with the systemd's
wiki page maintainer, I was impressed how many prejudments
he can made and how fast (already after the first letter).
This public disscussion is not an exception:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#628

Why nginx author doesn't have any needs to explain why his
software is superior to apache/lighttpd/etc in vast range
of usecases and so on?  And this is not unusual for other
projects.  Why?

If this situation is so specific for systemd, we
should count this as an argument against.  Is there
any similar example from the debian history?


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131203131454.ga6...@darkstar.order.hcn-strela.ru

Bug#727708: systemd code documentation

2013-12-03 Thread Russ Allbery 
Tollef Fog Heen  writes:

> Did you see the «Documentation for Developers» section on
> http://www.freedesktop.org/wiki/Software/systemd/ ?  It's more of an
> overview/design doc than function documentation, but it might be some of
> what you're looking for.

> I've also forwarded your question to Lennart on IRC, he might have even
> more pointers.

This documentation is really, really nice, but it's a bit different than
what I was talking about.  I should be clear, though (and please also do
mention this to Lennart): the user-facing and the integration
documentation for systemd seems quite good.  This is more the code-level,
helping the programmer sort of documentation, which is a bit lower-level.

Both upstart and systemd seem to have excellent manuals and high-level
design and interface documentation.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pppe2v97@windlord.stanford.edu

Bug#727708: systemd code documentation

2013-12-03 Thread Tollef Fog Heen 
]] Russ Allbery 


> My question here is: am I missing something in systemd?  Did I just look
> at the wrong files, or not look deeply enough, or is there orientation
> documentation somewhere else where I didn't see it?  Is there something
> about this comparison that's unfair?

Did you see the «Documentation for Developers» section on
http://www.freedesktop.org/wiki/Software/systemd/ ?  It's more of an
overview/design doc than function documentation, but it might be some of
what you're looking for.

I've also forwarded your question to Lennart on IRC, he might have even
more pointers.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871u1ue4pi@qurzaw.varnish-software.com

Bug#727708: systemd (security) bugs

2013-12-03 Thread Tollef Fog Heen 
]] Russ Allbery 

> Don Armstrong  writes:
> 
> > Projects which have multiple components, each of which has different
> > security/interface surfaces without stable defined interfaces, can lead
> > to problems when one set of developers doesn't understand the security
> > implications of the parts that they do not work on.
> 
> It's unclear to me that this is a correct characterization of systemd.  Do
> the separate components of systemd not have stable, defined interfaces?  I
> know they largely don't have other implementations, but that's not the
> same thing.

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

has a table with the various interfaces and their status.

[...]

> Let me put it this way.  I think there are a couple of givens here, some
> of which have been expressed by both the GNOME maintainers and the KDE
> maintainers and which are also reflected by the current state of Ubuntu:
> 
> * We use udev as the default device management platform and will continue
>   to do so regardless of the init system we choose.

Agreed.

> * Many of the other systemd services, particularly logind but also several
>   of the others, are quite desirable or even necessary for desktop
>   environments, so we will need to adopt those services in Debian
>   regardless of what init system we choose.  Obviously, if we adopt
>   systemd, integrating those services into the distribution is quite
>   straightforward.  If we don't adopt systemd, there are some critical
>   missing integrations (relative to the normal systemd infrastructure)
>   that will have to be replaced.  The cgroups manager appears to be the
>   most significant one at the moment.
>
> If the interfaces for those supplemental components are actually unstable,
> that's going to pose problems all around, but I'm not sure how directly
> relevant to this discussion that is since we're going to have to deal
> with those components *anyway*.  Choosing a different init system than
> systemd is not going to let us ignore logind, since it's going to be a
> required component for a modern desktop.  (Although it would still be good
> to know if this is the case.)

TTBOMK, the page listed above is accurate, and yes, I think there are
components we should adopt no matter if we go for systemd or not.
Things like tmpfiles.d aren't terribly complex, but it adds complexity
to each and every init script that needs a writable directory in /run to
handle permissions, ownership and creation, rather than just having a
single declarative file listing what it needs and the bootup process
ensuring that exists.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878uw2e55j@qurzaw.varnish-software.com