The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Buffer overruns etc.

> I propose that we form a group which goes through all security-relevant
> source code with a fine comb, looks for possible weaknesses, and then
> takes appropriate action.  Could somebody please create an appropriate
> mailing list, and subscribe me?
> 
> There are three classes of software which need looking into:
> 
> a) suid programs, which a malicious user may use to gain privileges
> 
> b) programs which interface with an untrusted environment, e.g.
>    networking software.
> 
> c) Programs which, when run by user foo, may grant user bar foo's
>    privileges.

(BTW, I cannot see in what group ld.so fits, here. is that "d) ld.so"?)


Maybe to create an extra insentive, we could add a "security" field
to the packages[1]. All packages in the above list would start of
with something like "insecure" in that field (all packages outside
the above list would have something like "doesnotapply").

After some kind of source-code review has passed for the "insecure"
packages, the security field would be upgraded to "checked".

Then, people can list mark/configure system as eighter "secure" or 
"dontcare", and dpkg would refuse to install "insecure" packages
on "secure" system.

This will create a *lot* of irritation in the beginning, but it
will give an extra insentive for the security-aware to review
that one package they really need. And it will make it possible
eventually to setup a "checked" system.



[1] No, the names of the fields are not quite right. 
   "checked" should probably also list who checked it, using
   what methods (buffer overruns only, maybe other bugs, ...), and
   "doesnotapply" for software outside the list should probably
    be split too. But I hope the idea is clear.

    Maybe checked should even be a PGP signed letter where the
    checker describes 1) the MD5/SHA-1 of the source code checked
    (possibly individual files), 2) what checks he made. 
    (Then the maintainer would sign "I built the binary form the
    sources). But this can all get way too compilcated very fast.
    Just a "checkec"/"unchecked" field would be a good start, I
    think.

-- 
joost witteveen, joostje@debian.org
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .