23. mar. 2012 05.48 skrev letters.random13 <[email protected]>: > [caveat: no expertise in package / distro security, end user only. i'm > interested letting a user answer the question: how interested is distro X in > security?] That's a good angle, considering that our users are the vendors who'll make products using Mer.
> > assuming that lack of doc on wiki & ~empty placeholder MER#161 mean there is > no proposed CVE-tracking infrastructure for mer, here are some options in > need of expert comment: > > (1) > http://www.enricozini.org/2011/debian/distromatch/ > http://wiki.debian.org/DEHS > http://distrowatch.com/packages.php > oswatershed.org > > maybe suited to tracking upstream package version numbers (MER#97) by > tracking pkgs in other distros, but not for tracking package CVE's directly. > > (2) follow meego procedure? (common to desktop vendors also) > > (a) CVE -> (b) meego bug report -> (c) updated packages [changelog > references CVE id (mostly); sometimes only references the bug id (not so > good)] -> (d) meego security advisory bug id having to include CVE can be enforced in Mer automated change checks if needed > > currently mer has placeholders for none of this? We do not currently, the question is also philosophical, how do we effectively deal with the incoming bug reports, how do we balance transparency vs security, should we set up a security team, how do they work etc. I can only say that we're obviously interested and think we should have proper and sane security - we're moving to a world where devices are to say the least, promiscious. The ability is there for anyone to pioneer this area in Mer, start writing up procedures, getting people involved, etc. The MeeGo method seems sane and it was done by people who took security very seriously. Copying other project's methods also works for me. > (but maybe mer infrastructure component IT Private is a placeholder for > (secure) bug report (b) or mer-SA (d))? > > meego had mailing list: > http://lists.meego.com/listinfo/meego-security > > with mails w/ subject like: > [MeeGo-security] [MeeGo-SA-10:21.libpng] Buffer overflow in libpng might > allow a > rbitrary code > > w/ content that referenced: > MeeGo BID: 3855 > CVE: CVE-2010-1205 > etc. > > the bug BID, > http://bugs.meego.com/show_bug.cgi?id=3855 > > had title like > CVE-2010-1205 [libpng] libpng row data buffer overflow > > with bugzilla tags like: > Product: Security > URL: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-1205 > > with content containing the complete CVE text. > > and the fixed package has a changelog entry like: > <changelog author="Bin Gao <[email protected]> - 1.2.44" > date="1278331200">- Update to 1.2.44 which includes CVE fix for > CVE-2010-1205 and CVE-2010-2249 > > so, it is/was relatively easy to search bugzilla or changelogs, etc. for > CVE's that had been treated. > > ----------- > if (2) is suitable, at least initially: > > i hacked some stuff together following what is done at: > https://www.redhat.com/security/data/metrics > and using repodata. (equivalent could be done using gerrit/git contents, > probably) > > (a) for each mer release, define a unique CPE, e.g., > i made up these entries based on repodata: > Release id Common Product Enumeration Deprecated? > 0.20120120.1 cpe:/o:merproject:mer:0.20120120.1 True > 0.20120209.1 cpe:/o:merproject:mer:0.20120209.1 True > 0.20120315.1 cpe:/o:merproject:mer:0.20120315.1 False > > this is trivial. ('deprecated' -> end-of-life -> only care about current > release? or try to maintain multiple releases (more work)?) Right now we're moving in a linear fashion, but the intended idea is that fixes can theoretically go into any given release branch and individual releases made, for example, mer 0.20120120.2 with security fixes or other needed fixes. It all depends on who wants to take on/share the work on backporting/who's using it. > > (b) for each release, generate a 'package' or 'product' list, e.g., > cpe:/o:merproject:mer:0.20120315.1/python > > this is mostly trivial. > > (c) map each package (main package; sub-packages are implicitly treated) to > a 'standard' CPE. > common external packages already have well-known CPE's, e.g., > python cpe:/a:python:python > python:2.6 cpe:/a:python:python:2.6 > python:2.6.5 cpe:/a:python:python:2.6.5 > coreutils cpe:/a:gnu:coreutils We can potentially autogenerate this through OBS build output if needed, or through release process/packaging. Some questions do pop up though, such as how do you assess something is a package that does contain a patch for a CVE too. > > new, uncommon or internal packages likely don't have CPE's, but it is in the > best interest of CVE tracking to have them assigned. > > using the official-cpe-dictionary_v2.2.xml, i found about 30 cpe hits for > mer main packages (~348 main packages, 515 sub-packages). > turns out that the official dictionary doesn't have all CPE's that occur in > CVE db. i'll have to redo the list using the CVE db. > in any case, only ~10% of main mer packages can be currently tracked in CVE. > whether it is worth maintaining this proposed infrastructure for only ~10% > of packages is tbd. > an alternative may be to just pay attention to upstream vendor rss feeds (if > any). > > note also that the CPE/CVE db's have zero mention of > moblin/maemo/meego/tizen, etc., but they do contain references to a few > android apps; so it is not clear that mobile distro's have bought in (or > caught up) to this approach. it is well entrenched in the linux / mac / > windows desktop world. > > (d) use the well-known CPE to search the CVE database (~xml file, few to > many MB in size). > the online search is at > http://web.nvd.nist.gov/view/vuln/search > > the CVE db is updated hourly or at least daily. > there is a timelag (a few days?) between when the vendors release fixes and > when the mentioned CVE's show up in the CVE db. this is maybe the window of > opportunity. for reference, RHEL6 claims 98% of critical flaws are fixed in > 1 day. > > to bootstrap mer, the historical data will have to be searched once to find > / clarify the status of all related / inherited CVE's. subsequently, only > the CVE updates (rss feed available) need be searched regularly for new > vulnerabilities. > > this is ~trivially automated for well-known CPE's, even to the point of > generating a new bug report; for non-well-known cpe's, it could probably > just flag potential CPE's (via keywords) for review by the package > maintainer, ranking them by the CVE CVSS severity. > > (e) a CPE match in the CVE db is also a good indication that a new (security > fix, at least) version of the package/product is available upstream (re: > MER#97). > > in the tentative list of CPE's i built for major mer packages, there are > currently exposed CVE's, some recent, others not so. > i hesitate to put the full list of older CVE's or packages in the general > mailing list, or even on the open bugzilla, though this info is publically > available. > > should i submit the list (1 CVE (per package?) per bug?) to the IT Private > component in bugzilla? > https://bugs.merproject.org/page.cgi?id=bug-writing.html doesn't describe > process One CVE bug per package makes sense. I'm aware there are a couple of probable CVEs to be fixed and the more overview of where our vulnerabilities we have, the better. We need to define a proper policy for security bugs and what flags need to be set for them, what team gets access to review them, when they are put available for general public to see, etc. And then there's the whole vendor angle on things. I think initially it's just best to admit we have some security bugs and it's best to get them included - being aware they exist is better than being unaware of them. So just go ahead and get them filed and we can get them fixed ASAP. I think you have the right idea of Mer security, something you'd like to help establish the area of or at least write up proposal of how it could be designed? BR Carsten Munk > > >
