New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Documentation] Retrieve CVEs for systemd own bugs and log them on git-log #5144

Closed
MikhailKasimov opened this Issue Jan 24, 2017 · 14 comments

Comments

7 participants
@MikhailKasimov
Contributor

MikhailKasimov commented Jan 24, 2017

Submission type

  • Request for enhancement (RFE)

systemd version the issue has been seen with

ANY

Hello!

Don't know if systemd developers track the seclists.org/oss-sec/ site, but here is the idea of retrieving CVEs for systemd own bugs and logging them on to its git log. See: http://seclists.org/oss-sec/2017/q1/175 :

We would like to see that systemd upstream retrieves CVE's themself for their own bugs,
even if its believed that its just a local DoS.
This would make distributors life much easier when we read the git logs to spot potential issues.
The systemd git log is really huge, with lots of commits each week ("new services as a service").

Doable?

@martinpitt

This comment has been minimized.

Show comment
Hide comment
@martinpitt

martinpitt Jan 24, 2017

Contributor

We can't retroactively put the CVE numbers into the commit logs, but we could tag a comit that fixes an issue with CVE-*. I believe there is also another git concept where you can add annotations to past commits, which we had used in the past to mark bug fix commits which are useful for backporting. It's apparently not "annotations" (git-annotate is something else), but something like that, can someone remember?

Contributor

martinpitt commented Jan 24, 2017

We can't retroactively put the CVE numbers into the commit logs, but we could tag a comit that fixes an issue with CVE-*. I believe there is also another git concept where you can add annotations to past commits, which we had used in the past to mark bug fix commits which are useful for backporting. It's apparently not "annotations" (git-annotate is something else), but something like that, can someone remember?

@mbiebl

This comment has been minimized.

Show comment
Hide comment
@mbiebl

mbiebl Jan 24, 2017

Contributor

It was git notes iirc

Contributor

mbiebl commented Jan 24, 2017

It was git notes iirc

@poettering poettering added the RFE 🎁 label Feb 1, 2017

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Feb 1, 2017

Member

i don't see how the quoted text from that security mailing list would request us to store CVE information in log messages. They want us to request CVE assignments directly from them, when we encounter bugs. I am not sure I buy enough into the security circus to do that though for any minor issue... It's also particularly hard if the impact of a bug isn't obvious. After all, how should we report CVEs for bugs that we (mis-)judge as (ir-)relevant? I also doubt the usefulness of CVEs is helped if we'd swamp them with irrelevant noise...

(also, does github even show git notes?)

Hence, I doubt the security community requests what is asked for in this issue. And I am pretty sure it's not our job as developers to file CVEs for any bug – regardless how small – we encounter. CVEs are after all not our currency, but the security community's...

Anyway, closing this here. I hope the above makes some sense.

Member

poettering commented Feb 1, 2017

i don't see how the quoted text from that security mailing list would request us to store CVE information in log messages. They want us to request CVE assignments directly from them, when we encounter bugs. I am not sure I buy enough into the security circus to do that though for any minor issue... It's also particularly hard if the impact of a bug isn't obvious. After all, how should we report CVEs for bugs that we (mis-)judge as (ir-)relevant? I also doubt the usefulness of CVEs is helped if we'd swamp them with irrelevant noise...

(also, does github even show git notes?)

Hence, I doubt the security community requests what is asked for in this issue. And I am pretty sure it's not our job as developers to file CVEs for any bug – regardless how small – we encounter. CVEs are after all not our currency, but the security community's...

Anyway, closing this here. I hope the above makes some sense.

@poettering poettering closed this Feb 1, 2017

@andreasstieger

This comment has been minimized.

Show comment
Hide comment
@andreasstieger

andreasstieger Feb 2, 2017

I think what @sebastian-suse wanted to express in his post to the oss-security mailing list was the following:

The original issue was committed as a fix for a local DoS. Requesting and assigning CVEs for this type of vector is perfectly feasible. If so, someone may have pointed out that this was in fact a local privilege escalation issue much earlier.

I do not think that concurrency is required here. If the developers consider an issue minor, a section in the release notes would help. In any case the keyword "local DoS" ought to trigger something in the mind of the capable developer or release manager, considering the "availability" protection target.

This may not be your particular project focus, as you mentioned CVEs as a currency rather than an method for organizing things. The security teams of distributions and CNAs will gladly help with this.

andreasstieger commented Feb 2, 2017

I think what @sebastian-suse wanted to express in his post to the oss-security mailing list was the following:

The original issue was committed as a fix for a local DoS. Requesting and assigning CVEs for this type of vector is perfectly feasible. If so, someone may have pointed out that this was in fact a local privilege escalation issue much earlier.

I do not think that concurrency is required here. If the developers consider an issue minor, a section in the release notes would help. In any case the keyword "local DoS" ought to trigger something in the mind of the capable developer or release manager, considering the "availability" protection target.

This may not be your particular project focus, as you mentioned CVEs as a currency rather than an method for organizing things. The security teams of distributions and CNAs will gladly help with this.

@martinpitt

This comment has been minimized.

Show comment
Hide comment
@martinpitt

martinpitt Feb 2, 2017

Contributor

The original issue was committed as a fix for a local DoS. Requesting and assigning CVEs for this type of vector is perfectly feasible

I disagree -- a local DoS is thoroughly uninteresting at least in Linux; there are numerous legitimate and much simpler ways to DoS your machine, issuing CVEs and security updates for things like this is just busywork and will distract attention from the actually important issues.

Contributor

martinpitt commented Feb 2, 2017

The original issue was committed as a fix for a local DoS. Requesting and assigning CVEs for this type of vector is perfectly feasible

I disagree -- a local DoS is thoroughly uninteresting at least in Linux; there are numerous legitimate and much simpler ways to DoS your machine, issuing CVEs and security updates for things like this is just busywork and will distract attention from the actually important issues.

@andreasstieger

This comment has been minimized.

Show comment
Hide comment
@andreasstieger

andreasstieger Feb 2, 2017

Distribution security teams are perfectly happy to score and issue collective updates covering minor issues, or not issuing them at all. Or, as in this case, let you know if we think that the severity may be different.

andreasstieger commented Feb 2, 2017

Distribution security teams are perfectly happy to score and issue collective updates covering minor issues, or not issuing them at all. Or, as in this case, let you know if we think that the severity may be different.

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 2, 2017

Member

@andreasstieger , not sure I understand. Distribution security teams don't really read the systemd git log (for example, f134289, cf447cb) because

The systemd git log is really huge, with lots of commits each week

Right?

Member

evverx commented Feb 2, 2017

@andreasstieger , not sure I understand. Distribution security teams don't really read the systemd git log (for example, f134289, cf447cb) because

The systemd git log is really huge, with lots of commits each week

Right?

@andreasstieger

This comment has been minimized.

Show comment
Hide comment
@andreasstieger

andreasstieger Feb 2, 2017

At this time, the systemd commit log is not something (my team) monitors.

As for the "busywork" argument, CVE-2016-10156 is an example of where this can go wrong, actually be a local root exploit.

I am not sure where to take it from here. The request remains to have some kind of policy of communicating potentially security relevant changes to downstream stakeholders, which can then do what they want or must do with it. Also do not under-estimate the back-flow of patches, corrections and testing.

andreasstieger commented Feb 2, 2017

At this time, the systemd commit log is not something (my team) monitors.

As for the "busywork" argument, CVE-2016-10156 is an example of where this can go wrong, actually be a local root exploit.

I am not sure where to take it from here. The request remains to have some kind of policy of communicating potentially security relevant changes to downstream stakeholders, which can then do what they want or must do with it. Also do not under-estimate the back-flow of patches, corrections and testing.

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 2, 2017

Member

As for the "busywork" argument, CVE-2016-10156 is an example of where this can go wrong, actually be a local root exploit

Well, the commit message doesn't contain the real impact. But I don't really understand how can security-minded reader miss basic: fix touch() creating files with 07777 mode

I thought that security people read/review systemd. I was wrong.

Indeed, we need

some kind of policy of communicating potentially security relevant changes to downstream stakeholders

but I'm not sure what to do about it

Member

evverx commented Feb 2, 2017

As for the "busywork" argument, CVE-2016-10156 is an example of where this can go wrong, actually be a local root exploit

Well, the commit message doesn't contain the real impact. But I don't really understand how can security-minded reader miss basic: fix touch() creating files with 07777 mode

I thought that security people read/review systemd. I was wrong.

Indeed, we need

some kind of policy of communicating potentially security relevant changes to downstream stakeholders

but I'm not sure what to do about it

@MikhailKasimov

This comment has been minimized.

Show comment
Hide comment
@MikhailKasimov

MikhailKasimov Feb 2, 2017

Contributor

how can security-minded reader miss basic: fix touch() creating files with 07777 mode

To mark such things with big bold red letters [SECURITY-ISSUE]?

Contributor

MikhailKasimov commented Feb 2, 2017

how can security-minded reader miss basic: fix touch() creating files with 07777 mode

To mark such things with big bold red letters [SECURITY-ISSUE]?

@stealth

This comment has been minimized.

Show comment
Hide comment
@stealth

stealth Feb 2, 2017

stealth commented Feb 2, 2017

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 2, 2017

Member

To mark such things with big bold red letters [SECURITY-ISSUE]

@MikhailKasimov, this doesn't work. You should read/try to break/... other things anyway (if you really care)

The problem is the lack of the communication. lets-communicate-via-CVEs-solution was rejected. Other ideas? Why not to communicate via code review/testing/audit? This helps to prevent bad things. And that's better than react to incidents. No?

Member

evverx commented Feb 2, 2017

To mark such things with big bold red letters [SECURITY-ISSUE]

@MikhailKasimov, this doesn't work. You should read/try to break/... other things anyway (if you really care)

The problem is the lack of the communication. lets-communicate-via-CVEs-solution was rejected. Other ideas? Why not to communicate via code review/testing/audit? This helps to prevent bad things. And that's better than react to incidents. No?

@MikhailKasimov

This comment has been minimized.

Show comment
Hide comment
@MikhailKasimov

MikhailKasimov Feb 2, 2017

Contributor

@evverx In ideal case -- yes and I totally agree with you here. But idea of big bold red letters [SECURITY-ISSUE]-solution, which was an attempt to handle non-ideal case, seemed normal via its parseable via grep for those distros, which have some communication inertia. No problem to try to find out other ideas...

Contributor

MikhailKasimov commented Feb 2, 2017

@evverx In ideal case -- yes and I totally agree with you here. But idea of big bold red letters [SECURITY-ISSUE]-solution, which was an attempt to handle non-ideal case, seemed normal via its parseable via grep for those distros, which have some communication inertia. No problem to try to find out other ideas...

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Feb 3, 2017

Member

To mark such things with big bold red letters [SECURITY-ISSUE]?

Rewriting git history is not acceptable, hence we cannot mark this in the git commits. I also doubt that people would even look for CVE info in the git log. We could track it in a CVE.md file in our git repo of course, but I am not sure people would look there either. If people look somewhere, then it's certainly the CVE database itself, and there's no need to duplicate this in our tree, in particular as it would be necessarily out of date, and a number of CVEs I really don't went to bless with any respect from our side, like the hubbub they made about the sd_notify() issue... meh!

I find the whole discussion pointless. It's about communicating something we (mis-)judged as not being relevant. I mean, if we thought it was relevant, we could have communicated it, but the key is we didn't think it was relevant. An no, we won't flood people with everything irrelevant under the earth. Sorry. That's not going to be helpful, and would drown the relevant bits in noise.

Yes, it is our fault that we (mis-)judged it as irrelevant, but the action that resulted from it, was the right one from that judgement.

And please, let's leave it at that.

Member

poettering commented Feb 3, 2017

To mark such things with big bold red letters [SECURITY-ISSUE]?

Rewriting git history is not acceptable, hence we cannot mark this in the git commits. I also doubt that people would even look for CVE info in the git log. We could track it in a CVE.md file in our git repo of course, but I am not sure people would look there either. If people look somewhere, then it's certainly the CVE database itself, and there's no need to duplicate this in our tree, in particular as it would be necessarily out of date, and a number of CVEs I really don't went to bless with any respect from our side, like the hubbub they made about the sd_notify() issue... meh!

I find the whole discussion pointless. It's about communicating something we (mis-)judged as not being relevant. I mean, if we thought it was relevant, we could have communicated it, but the key is we didn't think it was relevant. An no, we won't flood people with everything irrelevant under the earth. Sorry. That's not going to be helpful, and would drown the relevant bits in noise.

Yes, it is our fault that we (mis-)judged it as irrelevant, but the action that resulted from it, was the right one from that judgement.

And please, let's leave it at that.

@systemd systemd locked and limited conversation to collaborators Jul 29, 2017

@systemd systemd deleted a comment from revmischa Jul 29, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.