Security reviews for new packages

[Jason L Tibbitts III]

I do many package reviews, and occasionally I see a package that is
fine packaging-wise but which I don't feel comfortable approving
because I know it has security implications.  One such package is
schroot, which has some pam magic to allow users to set up chroots.
  https://bugzilla.redhat.com/show_bug.cgi?id=447368

It's quite possible that I'm simply being overly paranoid, but of
course I'm not qualified to say one way or the other.  Is it possible
for someone with more knowledge in this area to take a look at the
package?  What would be needed?  (Perhaps a scratch build, or are the
src.rpm and spec sufficient?)

Could we work out a simple procedure for doing this in the future?

 - J<

[Kevin Fenzi]

On 11 Nov 2008 09:51:23 -0600
Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:

>  I do many package reviews, and occasionally I see a package that is
>  fine packaging-wise but which I don't feel comfortable approving
>  because I know it has security implications.  One such package is
>  schroot, which has some pam magic to allow users to set up chroots.
>    https://bugzilla.redhat.com/show_bug.cgi?id=447368
>  
>  It's quite possible that I'm simply being overly paranoid, but of
>  course I'm not qualified to say one way or the other.  Is it possible
>  for someone with more knowledge in this area to take a look at the
>  package?  What would be needed?  (Perhaps a scratch build, or are the
>  src.rpm and spec sufficient?) 
I'm no expert, but I could take a look I suppose. 

>  Could we work out a simple procedure for doing this in the future?
How about we make a F_SECURITY_REVIEW tracker bug, and any review that
needs extra security attention is made to block that bug. We can add
this list to that blocker to notify everyone here to take a look?
(It's worked for LEGAL I think, so I would hope it works for security
reviews as well). 

Thoughts?

>   - J< 
kevin

[Jason L Tibbitts III]

> >>>> "KF" == Kevin Fenzi <kevin(a)tummy.com&gt;
> writes: 
KF> I'm no expert, but I could take a look I suppose.

Another pair of eyes won't hurt, of course, but honestly I don't know
what's involved in an actual secuity review.

KF> How about we make a F_SECURITY_REVIEW tracker bug, and any review
KF> that needs extra security attention is made to block that bug.

Well, that would work but I'm thinking it's a bit premature to talk
about it until we know that there's at least one proper trained
security person who will actually pay attention to it.

I just don't want to have the security team's first contact with a
package like this to be the posting of CVEs.

 - J<

[Mamoru Tasaka]

Jason L Tibbitts III wrote, at 11/12/2008 12:51 AM +9:00:
>  I do many package reviews, and occasionally I see a package that is
>  fine packaging-wise but which I don't feel comfortable approving
>  because I know it has security implications.  One such package is
>  schroot, which has some pam magic to allow users to set up chroots.
>    https://bugzilla.redhat.com/show_bug.cgi?id=447368
>  
>  It's quite possible that I'm simply being overly paranoid, but of
>  course I'm not qualified to say one way or the other.  Is it possible
>  for someone with more knowledge in this area to take a look at the
>  package?  What would be needed?  (Perhaps a scratch build, or are the
>  src.rpm and spec sufficient?)
>  
>  Could we work out a simple procedure for doing this in the future?
>  
>   - J< 
Some days ago my potential sponsornee submitted a review request,
which (according to the explanation) uses chroot() and has some
setuid binaries. I guess I can "basic" reviews also required for
other packages, however for security matters I really applicate
any help from who knows how to deal with securitly issues.

https://bugzilla.redhat.com/show_bug.cgi?id=479546
- Jailkit limits user accounts to specific files and/or commands

Regards,
Mamoru

[Jason L Tibbitts III]

> >>>> "MT" == Mamoru Tasaka
> <mtasaka(a)ioa.s.u-tokyo.ac.jp&gt; writes: 
MT> I guess I can "basic" reviews also required for other packages,
MT> however for security matters I really applicate any help from who
MT> knows how to deal with securitly issues.

Well, my request didn't result in any assistance, so I'm not terribly
optimistic about being able to do this more generally.  I'm just going
to review security-sensitive packages as well as I can and make a note
here when I'm doing it.  If one of these packages later turns up with
a major exploit and someone wants to flame me for not blocking on more
serious security review, I suppose they're welcome to pound sand.

 - J<