Gentoo Linux security discussion

Matthias Geerdsen | 13 Jul 2008 01:18

Security project meeting - Monday, 2008-07-14, 19:00 UTC

Hi everyone,

the security project will hold a public meeting in #gentoo-security this monday, 
2008-07-14 at 19:00 UTC (21:00 CEST).
The tentative agenda looks as follows:

1) Project status

2) Recruitment

3) Delays in bug resolution/GLSA publication

4) GLSA related issues
   4.1) new date format
   4.2) slot support

5) Handling of CVE identifiers in bugs

6) Possible changes to the Vulnerability Policy
   6.1) Rating for "insecure creation of temporary files"
   6.2) Rating for "SQL injection"

7) Security support for games

8) Any other topic

Any changes to the agenda as well as related info can be found at [1].

[1] <http://dev.gentoo.org/~vorlon/security/meeting-20080714.xml>

(Continue reading)

headers

Matthias Geerdsen | 21 Jul 2008 20:49

Security project meeting summary

Hi,

I attached a summary of last week's meeting. The summary and the log are also 
linked from [1] and should find their way to our /proj dir in the end.

Matthias

[1] <http://dev.gentoo.org/~vorlon/security/meeting-20080714.xml>

-- 
Matthias Geerdsen
vorlon <at> gentoo.org

Gentoo Linux Security Team
http://security.gentoo.org

Gentoo Security Project Meeting 2008-07-14
******************************************

Agenda
------

1) Project status
2) Recruitment
3) Delays in bug resolution/GLSA publication 
4) GLSA related issues
  4.1) New date format in GLSAs
  4.2) Slot support
5) Handling of CVE identifiers in bugs

(Continue reading)

headers

Aleksey V Lazar | 21 Jul 2008 21:04

Re: Security project meeting summary

Hello.  Would it be reasonable to suggest adding a ~security (or 
something like it) flag to denote packages masked for security reasons?

Thanks.
Aleksey

Matthias Geerdsen wrote:
> Hi,
>
> I attached a summary of last week's meeting. The summary and the log 
> are also linked from [1] and should find their way to our /proj dir in 
> the end.
>
> Matthias
>
>
> [1] <http://dev.gentoo.org/~vorlon/security/meeting-20080714.xml>
>

--

-- 
Aleksey V. Lazar
Website Development
Memorial Library 3010
Minnesota State University
Mankato, MN 56001
http://www.mnsu.edu/
Tel.: 1-507-389-2480

headers

Robert Buchholz | 22 Jul 2008 12:42

Re: Security project meeting summary

On Monday 21 July 2008, Aleksey V Lazar wrote:
> Hello.  Would it be reasonable to suggest adding a ~security (or
> something like it) flag to denote packages masked for security
> reasons?

Hi Aleksey,

since entries package.mask only contain free text description as an 
additional information, such a feature would require the package 
manager to decide which entries are security maskings, and which are 
feature maskings. While that could be done using 
restrictions/conventions within the text, I am sure our package manager 
developers would disagree with such a design. A "package.security.mask" 
file might be more appropriate for that.

My question now is, why would you want such a thing? Masked packages all 
have different reasons to be there, and you should decide to use one on 
a case-by-case basis.

Regards,
Robert

headers

Paige Thompson | 22 Jul 2008 20:01

Re: Security project meeting summary

misfit[1004]:~% sudo emerge -uva nethack
Password:

These are the packages that would be merged, in order:

Calculating dependencies |
!!! All ebuilds that could satisfy "games-roguelike/nethack" have been masked.
!!! One of the following masked packages is required to complete your request:
- games-roguelike/nethack-3.4.3-r1 (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Tavis Ormandy <taviso <at> gentoo.org> (21 Mar 2006)
# masked pending unresolved security issues #125902

For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.

misfit[1005]:~%

On Tue, Jul 22, 2008 at 3:42 AM, Robert Buchholz <rbu <at> gentoo.org> wrote:

On Monday 21 July 2008, Aleksey V Lazar wrote:
> Hello. Would it be reasonable to suggest adding a ~security (or
> something like it) flag to denote packages masked for security
> reasons?

Hi Aleksey,

since entries package.mask only contain free text description as an
additional information, such a feature would require the package
manager to decide which entries are security maskings, and which are
feature maskings. While that could be done using
restrictions/conventions within the text, I am sure our package manager
developers would disagree with such a design. A "package.security.mask"
file might be more appropriate for that.

My question now is, why would you want such a thing? Masked packages all
have different reasons to be there, and you should decide to use one on
a case-by-case basis.

Regards,
Robert

headers

Robert Buchholz | 22 Jul 2008 21:04

Re: Security project meeting summary

On Tuesday 22 July 2008, Paige Thompson wrote:
> misfit[1004]:~% sudo emerge -uva nethack
> Password:
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies |
> !!! All ebuilds that could satisfy "games-roguelike/nethack" have
> been masked.
> !!! One of the following masked packages is required to complete your
> request:
> - games-roguelike/nethack-3.4.3-r1 (masked by: package.mask)
> /usr/portage/profiles/package.mask:
> # Tavis Ormandy <taviso <at> gentoo.org> (21 Mar 2006)
> # masked pending unresolved security issues #125902
>
>
> For more information, see MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook.

Sorry, I do not understand the point you are trying to make. Nethack has 
an unresolved security bug, and if you want to install it anyway, put 
it in your /etc/portage/package.unmask  -- as described in
"man emerge". I do not see the gain by setting up a system that would 
completely ignore *all* security-related package masks.

Robert

headers

Aleksey V Lazar | 24 Jul 2008 19:20

Re: Security project meeting summary

Pierre-Yves Rofes wrote:

On Mon, July 21, 2008 9:04 pm, Aleksey V Lazar wrote:
Hello. Would it be reasonable to suggest adding a ~security (or something like it) flag to denote packages masked for security reasons? Thanks. Aleksey
Hello, by "~security" you mean a keyword like ~x86 ? It's not a hardware architecture, so it wouldn't make much sense. But having a way to list masked packages for security reasons is indeed a good idea. The problem is finding how to do it "the right way". -- Pierre-Yves Rofes Gentoo Linux Security Team

I was thinking more along the lines of adding a special mark to the list that currently includes "~", "+" and "M". Let's say it would be "!". This mark could then be used for package versions with security problems. I don't know if this is technically possible, but I could see "!" used in conjunction with the "~", "+" or "M" to alert/indicate a security issue, like "~!", or "+!" or "M!". I think this is what I meant.

Thanks.
Aleksey

-- Aleksey V. Lazar Website Development Memorial Library 3010 Minnesota State University Mankato, MN 56001 http://www.mnsu.edu/ Tel.: 1-507-389-2480

headers

Aleksey V Lazar | 29 Jul 2008 00:08

Re: Security project meeting summary

Hello, Robert:

Robert Buchholz wrote:

On Monday 21 July 2008, Aleksey V Lazar wrote:
Hello. Would it be reasonable to suggest adding a ~security (or something like it) flag to denote packages masked for security reasons?
Hi Aleksey, since entries package.mask only contain free text description as an additional information, such a feature would require the package manager to decide which entries are security maskings, and which are feature maskings. While that could be done using restrictions/conventions within the text, I am sure our package manager developers would disagree with such a design. A "package.security.mask" file might be more appropriate for that.

Are you saying that security mask entries would go into the package.security.mask and feature/other to package.mask? I think this would make sense.

My question now is, why would you want such a thing? Masked packages all have different reasons to be there, and you should decide to use one on a case-by-case basis.

I described in some more detail what I was thinking about in my previous post to this list.

To answer your question, I think a feature like this would be very useful, because it would remove barriers for identifying packages with security issues. For example, I don't update my gentoo system daily, but I would update it as often as necessary to keep it secure. Currently (to the best of my understanding) there is no easy way (e.g.: an emerge option) to identify and update only the packages that have security fixes. I would have to do some digging to find out what packages and evaluate each package separately. So I think there would be value in separating security masking from other types. To summarize, I think this would accomplish the following:

1. Easily identify packages masked for security reasons.
2. Easily identified installed packages that have security issues/fixes available.
3. Option for emerge to only update packages with security fixes

Thank you for consideration.
Aleksey

Regards, Robert

-- Aleksey V. Lazar Website Development Memorial Library 3010 Minnesota State University Mankato, MN 56001 http://www.mnsu.edu/ Tel.: 1-507-389-2480

headers

Bill | 29 Jul 2008 01:33

Re: Security project meeting summary


> Currently (to the best of my understanding) there is no easy way (e.g.:
> an /emerge/ option) to identify and update only the packages that have
> security fixes.

 This doesn't work anymore?

   1. emerge --sync (emerge-webrsync)
   2. glsa-check -p affected
   3. glsa-check -f affected
   4. env-update
   5. revdep-rebuild

    Bill

headers

Robert Buchholz | 29 Jul 2008 04:13

Re: Security project meeting summary

On Tuesday 29 July 2008, Bill wrote:
> > Currently (to the best of my understanding) there is no easy way
> > (e.g.: an /emerge/ option) to identify and update only the packages
> > that have security fixes.
>
>  This doesn't work anymore?
>
>    1. emerge --sync (emerge-webrsync)
>    2. glsa-check -p affected
>    3. glsa-check -f affected
>    4. env-update
>    5. revdep-rebuild

GLSA support has also been integrated into Portage 2.2, so you can do 
something along the lines of
   # emerge --update  <at> security

Robert

1	May 2013
1	April 2013
1	September 2012
1	May 2012
1	April 2012
1	December 2011
2	November 2011
30	August 2011
1	May 2011
1	January 2011
15	October 2010
9	September 2010
3	August 2010
8	April 2010
5	December 2009
5	June 2009
4	May 2009
5	March 2009
5	January 2009
2	October 2008
3	August 2008
10	July 2008
4	May 2008
7	April 2008
29	March 2008
68	February 2008
4	September 2007
4	August 2007
2	May 2007
19	April 2007
1	February 2007
7	December 2006
24	November 2006
41	October 2006
21	September 2006
23	August 2006
25	July 2006
5	May 2006
22	April 2006
26	March 2006
54	February 2006
20	January 2006
4	December 2005
78	November 2005
127	October 2005
55	September 2005
15	August 2005
45	June 2005
34	May 2005
54	April 2005
65	March 2005
80	February 2005
104	January 2005
69	December 2004
269	November 2004
13	October 2004
23	September 2004
86	August 2004
126	July 2004
33	June 2004
69	May 2004
117	April 2004
196	March 2004
78	February 2004
147	January 2004
74	December 2003
30	November 2003
32	October 2003
80	September 2003
22	August 2003
14	July 2003
33	June 2003
25	May 2003
72	April 2003
120	March 2003
18	February 2003
24	January 2003
34	December 2002
12	November 2002
35	October 2002
23	September 2002
22	August 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31