Re: NSA software in Debian
On Sun, 19 Jan 2014, Marco Saller <marcosaller@yahoo.de> wrote:
> i am not sure if this question has been asked or answered yet, please do
> not mind if i would ask it again. Is it possible that the NSA or other
> services included investigative software in some Debian packages?
It is possible that a DD has betrayed the cause and willingly subverted a
package, in the past we had someone apply to become a DD who had a history of
doing such things. Fortunately they were caught and didn't become a DD, but
it's possible that someone else with similar ideas got through. This doesn't
make Debian any different to any other large project or organisation. Getting
1000+ people to work together and have no-one do crazy stuff is an impossible
problem to solve.
It's possible that a DD with good intentions has been blackmailed by an
external organisation. Again that's the same with any organisation.
One advantage that Debian has over proprietary software companies is that
there's no possibility of someone accepting a $10,000,000 payment and making
it policy to weaken Debian security the way that some proprietary software was
deliberately weakened.
On Sun, 19 Jan 2014, Noah Meyerhans <noahm@debian.org> wrote:
> It is absolutely possible. It's even possible that you yourself have
> added such software to Debian! Can you prove that you haven't?
>
> That line of thinking leads to madness. The only rational conclusion,
> once you start down that path, is to turn off your computers and move to
> a remote cabin in the wilderness. It will never be possible to prove
> that there is no malicious software in Debian or in any other OS. Beyond
> that, it will never be possible to prove that there is no malicious
> *hardware* running executing your OS.
>
> We can and do take care to ensure that all changes to Debian are made by
> people authorized to make those changes. (Package uploads must be signed
> by a Debian developer.) We can and do take care to ensure that that the
> packages you download have not been modified in transmission (signing of
> Release files, checksums on Packages files and on packages themselves.)
> Etc. If deficiencies are found in our mechanisms or policies, then we
> take steps to improve them. If violations are found, then we take steps
> to audit for impact and resolve any potentially malicious actions that
> we identify. We take great care to minimize the likelihood of any sort
> of backdoor or malicious code in Debian, but none of this can provide
> 100% proof that such a thing doesn't exist. Anybody that claims that
> they can prove otherwise, for Debian or any other OS, is either lying or
> ignorant.
Absolutely.
On Sun, 19 Jan 2014, Justin Andrusk <jandrusk@gmail.com> wrote:
> I would expect it to be root kit of some form, most likely to dwell in a
> non-free repo.
The vast majority of Linux systems are single-user systems. If a hostile
party gains access to the UID that's used for running one web browser, email
program, game, etc then they get it all. So getting root isn't required for
most hostile activity. That gives a much larger scope for attackers and a
much more difficult problem for the people who defend systems.
One thing to note in this regard is that the SE Linux development process
involves documenting what security critical apps do and allows review of them.
There have been more than a few application/daemon security problems that
allowed non-root compromises discovered by using SE Linux.
On Sun, 19 Jan 2014, Kevin Olbrich <kolbrich@dolphin-it.de> wrote:
> Even if there would not be a manipulated software package - hardware
> manipulation in mainboards or network hardware (like cisco does) is
> already known.
It is a documented fact that some government agencies can subvert hardware
between the factory and the user. However that is expensive and risky for
them so would only be done on high value targets. Most people need to be
concerned with the case where good hardware is delivered to them and is
compromised later. In that case hardware compromise (EG BIOS replacement) is
something that would only happen if the OS was compromised first. So we need
to concern ourselves with OS security.
On Sun, 19 Jan 2014, "Andreas Kuckartz" <a.kuckartz@ping.de> wrote:
> I proposed this Debian Release Goal:
> https://wiki.debian.org/ReleaseGoals/SELinux
Thanks.
On Mon, 20 Jan 2014, "JKAbrams.se" <j@jkabrams.se> wrote:
> We can not refrain from drawing conclusions because of their
> implications, if they indeed are correct, that would be self
> deception. The answer to the question is: Yes, it is indeed possible
> that an organisation with the NSA's budget and determination could
> have compromised a component of Debian, or any other open source
> software. Has there been any evidence to suggest this is the case? No.
> At least, not yet. (Remember, the publishing of the leaks are not
> random, and Greenwald has signed up for the owner of Paypal.)
> The task we have been reluctantly assigned is enormous, but is it also
> utterly hopeless? We have seen through the leaks that if there is an
> easy way in the NSA will already have it codenamed.
Organisations that collect exploits will use them in a strategic manner
(otherwise they wouldn't even get a collection). Exploits that are new and
unknown are valuable, they will be used on high value targets - and the
attackers can be expected to avoid targets that might discover the exploits.
https://lists.debian.org/debian-security-announce/2003/msg00212.html
The Debian sysadmin and security teams have been proven to be good at
discovering such things. A smart attacker would hesitate to use a new exploit
directly against Debian.
People who use Debian for personal use or for typical corporate use shouldn't
be too worried about such things. I'm sure that people who use FOSS software
for running sites like www.google.com lose a lot of sleep about such things.
> The more productive questions are: Where is the lowest bar and what
> could we do to raise it? There is good work ongoing here, for example
> deterministic builds [1], a vector of attack that can be provably
> eliminated [2]. But at the same time, let's not kid our selves. Let's
> step back and reflect on on the feasibility of the open source model
> in the face of adversaries like the NSA and their cohorts. When we
> trust the software, what are the presumptions upon which our trust
> rests and how easily can they be broken?
Let's not assume that the NSA is a monolithic organisation.
> The worst case from a "future of free software" sort of perspective
> would be a leak confirming our worst fears that a trusted person
> within free software was compromised. I can only hope that any such
> person leaves now, quietly, while leaving the full details about the
> hole[s] with someone to fix it before taking us all down RSA-style.
I don't agree that a compromise of a trusted person is necessarily the worst
thing. In military history there's been many compromises of trusted people,
but mistakes by honest people often cause worse results.
The aims of fixing mistakes don't necessarily go well with the aims of finding
traitors.
> [1] https://wiki.debian.org/ReproducibleBuilds
> [2]
> http://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-
> video.html
Thanks for the links.
On Mon, 20 Jan 2014, Marko Randjelovic <markoran@eunet.rs> wrote:
> SELinux security benefits are vague because it makes possible to use
> it's hooks to add a backdoor which would be nearly impossible to detect:
>
> https://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm
> https://grsecurity.net/lsm.php
>
> Consider alternatives like PaX/grsecurity and RSBAC.
Using LSM was a requirement for SE Linux to get included in kernel.org and
therefore get included in kernels built by Debian and other distributions.
Maintaining the SE Linux kernel patch separately was a major PITA (I was the
one doing this for Debian).
Being able to use SE Linux in a stock kernel from Debian, Red Hat, and some
other vendors saves some time which can be applied to securing other things.
Security is something that takes as much time as you have available for it, so
saving sysadmin time is a major security benefit.
The Debian kernel source tree has patches which generally make things work
better. While not all the patches that Debian includes will be relevant to my
systems it's a lot easier for me to just use Debian kernels and use the time I
save to work on other things.
The possibility of LSM hooks being used to hide a kernel rootkit is widely
cited. But most sysadmins aren't going to find a kernel rootkit anyway so
using a non-LSM security system for that reason is trading off the real
benefit of being able to save time and effort in maintaining systems for the
probably impossible theoretical benefit of not using LSM.
It would be nice if some of the other security systems could be submitted as
LSM modules. Then for the people who want such things there could be a patch
to make them not use LSM and use direct hooks instead.
On Mon, 20 Jan 2014, "Andreas Kuckartz" <a.kuckartz@ping.de> wrote:
> > Consider alternatives like PaX/grsecurity and RSBAC.
>
> Both seem to be compatible with SELinux.
PaX has been shown to work well with SE Linux, I think that the Gentoo people
did the most in that regard. But mixing SE Linux with another MAC system
probably doesn't make sense.
On Tue, 21 Jan 2014, Marco Saller <marcosaller@yahoo.de> wrote:
> I have read that the NSA proposed to include SELinux in linux 2.5. (Linux
> Kernel Summit 2001) Don't you think that may be one of their fancy tricks
> to gain access to computers running linux? Some news websites also mention
> vulnerabilities similar to this one. It would be a great idea to include
> malicious software to kernel modules.
Why would anyone do something bad in public under their own name? I think we
should be much more worried about random gmail addresses being used to send
kernel patches.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Reply to: