selinux stole my bank details (and my pony)
...it didn't really, but... is anyone still a selinux fanboi after the recent NSA revelations? if so then (Russell, I'm looking at you :-) why are you still confident selinux is a good thing and not just something designed to be so complex or so subtly buggy that the NSA can hide backdoors in it? there's already been one CVE where only those running selinux are vulnerable https://bugzilla.redhat.com/show_bug.cgi?id=517830 which at the time made me very happy I'd turned selinux off. Android 4.3 has started using selinux. do we really trust android vendors to be on top of complex selinux configs or would we be better off with it err, off? I doubt I'll be shipping my android roms with selinux on. that used to be 'cos I don't have the time to get it working and right, but now I also question its motivation and even the kernel implementation too. am I wrong? cheers, robin (yes, I've had a few and yes, this is a troll, but I'd still like to know if anyone's ever fully read and understood the implications of every distro selinux rule and every selinux line in the kernel - giving unaudited power to 3 letter agencies is not a sane way forward...)
Robin Humble <rjh+luv@cita.utoronto.ca> wrote:
...it didn't really, but... is anyone still a selinux fanboi after the recent NSA revelations?
if so then (Russell, I'm looking at you :-) why are you still confident selinux is a good thing and not just something designed to be so complex or so subtly buggy that the NSA can hide backdoors in it?
The code has been worked on extensively by people who are not associated with the NSA, so at this point I'm not concerned that it harbours intended vulnerabilities. Also remember that SELinux adds to the security of a system: the Linux discretionary access controls are checked first. Only if the operation is allowed is SELinux invoked to apply the security policy.
On Tue, 10 Sep 2013, Robin Humble <rjh+luv@cita.utoronto.ca> wrote:
...it didn't really, but... is anyone still a selinux fanboi after the recent NSA revelations?
Yes.
if so then (Russell, I'm looking at you :-) why are you still confident selinux is a good thing and not just something designed to be so complex or so subtly buggy that the NSA can hide backdoors in it?
http://etbe.coker.com.au/2013/07/23/security-is-impossible/ Firstly I've written some general thoughts about security at the above URL. Next if the NSA wanted to put some hostile code in the kernel then surely they would use a random gmail account to submit patches and not do anything bad under their own name. The so-called "revelations" aren't anything particularly exciting anyway. They merely confirm that some parts of the NSA recently started doing things that lots of people expected them to have been doing since the 90's.
there's already been one CVE where only those running selinux are vulnerable https://bugzilla.redhat.com/show_bug.cgi?id=517830 which at the time made me very happy I'd turned selinux off.
That was a theoretical vulnerability. Exploiting that relied on the presence of other buggy code that could be exploited, I don't recall any examples of such code being cited.
Android 4.3 has started using selinux. do we really trust android vendors to be on top of complex selinux configs or would we be better off with it err, off?
Given that Android systems tend to run for years without updates I think we want as many layers of security as possible.
(yes, I've had a few and yes, this is a troll, but I'd still like to know if anyone's ever fully read and understood the implications of every distro selinux rule and every selinux line in the kernel - giving unaudited power to 3 letter agencies is not a sane way forward...)
Apart from a few exceptions the SE Linux design is based on a default of deny and also is secondary to Unix permissions. SE Linux permits things that Unix permissions permit if there are specific rules for it. It's more difficult to go wrong with that sort of design. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker <russell@coker.com.au> wrote:
Next if the NSA wanted to put some hostile code in the kernel then surely they would use a random gmail account to submit patches and not do anything bad under their own name.
Agreed. Further, if any government wanted to subvert cryptography they could do it by trying to sneak code into OpenSSL, NSS or GNUTLS - and the vulnerability would have to be subtle enough to escape notice by the maintainers.
The so-called "revelations" aren't anything particularly exciting anyway. They merely confirm that some parts of the NSA recently started doing things that lots of people expected them to have been doing since the 90's.
Yes, exactly. What we don't know is whether any well-known cryptographic algorithms have been broken or weakened. As I recall however, the U.S. government is supposed to be moving toward elliptic curve cryptography, and the NSA has an interest in *protecting* the confidentiality of government information.
On 09/10/2013 10:48 AM, Jason White wrote:
Russell Coker <russell@coker.com.au> wrote:
Next if the NSA wanted to put some hostile code in the kernel then surely they would use a random gmail account to submit patches and not do anything bad under their own name.
Agreed. Further, if any government wanted to subvert cryptography they could do it by trying to sneak code into OpenSSL, NSS or GNUTLS - and the vulnerability would have to be subtle enough to escape notice by the maintainers.
The so-called "revelations" aren't anything particularly exciting anyway. They merely confirm that some parts of the NSA recently started doing things that lots of people expected them to have been doing since the 90's. Yes, exactly. What we don't know is whether any well-known cryptographic algorithms have been broken or weakened. As I recall however, the U.S. government is supposed to be moving toward elliptic curve cryptography, and the NSA has an interest in *protecting* the confidentiality of government information.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
George Orwell got it right!
Quoting Jason White (jason@jasonjgw.net):
Yes, exactly. What we don't know is whether any well-known cryptographic algorithms have been broken or weakened. As I recall however, the U.S. government is supposed to be moving toward elliptic curve cryptography, and the NSA has an interest in *protecting* the confidentiality of government information.
I put some stock in Bruce Schneier's assessment of that situation, which please see. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-survei... -- Cheers, "Girl, are you a model? Because you could totally be an Rick Moen idealized sample representation of a real-world object." rick@linuxmafia.com -- Matt Watson McQ! (4x80)
On 10.09.13 10:48, Jason White wrote:
Russell Coker <russell@coker.com.au> wrote:
Next if the NSA wanted to put some hostile code in the kernel then surely they would use a random gmail account to submit patches and not do anything bad under their own name.
Agreed. Further, if any government wanted to subvert cryptography they could do it by trying to sneak code into OpenSSL, NSS or GNUTLS - and the vulnerability would have to be subtle enough to escape notice by the maintainers.
Given the media reports of the NSA using several supercomputers to crack SSL traffic (with some degree of success apparently) it may be that they don't have anything but brute force and possibly a few cryptology tricks, so far. (Depending on how much credence is to be given to anything heard in the media.) Erik -- I sense much distrust in you. Distrust leads to cynicism, cynicism leads to bitterness, bitterness leads to the Awareness of True Reality which is referred to by those-who-lack-enlightenment as "paranoia" I approve. - fortune
Erik Christiansen writes:
Given the media reports of the NSA using several supercomputers to crack SSL traffic (with some degree of success apparently) it may be that they don't have anything but brute force and possibly a few cryptology tricks, so far. (Depending on how much credence is to be given to anything heard in the media.)
Turkish intelligence don't need to "crack" TLS; they just get Firefox to trust them by default, then do the normal MITM dance. I don't see why the NSA can't do that, too. http://www.cl.cam.ac.uk/~rja14/Papers/sefa-pr11.pdf (p2) | At the authentication workshop following FC2011 I asked a panelist | from the Mozilla Foundation why, when I updated Firefox the previous | day, it had put back a certificate I’d previously deleted, from an | organisation associated with the Turkish military and intelligence | services.
On 10.09.13 15:44, Trent W. Buck wrote:
Turkish intelligence don't need to "crack" TLS; they just get Firefox to trust them by default, then do the normal MITM dance. I don't see why the NSA can't do that, too.
Thanks, Trent, that link is eye-opening! My SSL fu isn't up to grokking how the cert would initially get onto his machine. Is the extra one sneaked in when firefox is pointed at a boobytrapped https page? If so, it'd pretty much take my bank or an electronic gadgetry vendor to perform the infiltration here. Oh-Oh, that's not true - just visiting a facebook page (without ever having signed up to the thing) has us https-ing. (It's time to find out where the certs hide, I guess) Erik -- Tecoma's Macca-striking flash mob: http://www.youtube.com/watch?v=H7-0T1vbnWE Stop fat food joint opposite Tecoma preschool: www.change.org What's cooking: https://www.facebook.com/pages/NO-McDonalds-in-The-Dandenong-Ranges/22041986...
Erik Christiansen <dvalin@internode.on.net> writes:
On 10.09.13 15:44, Trent W. Buck wrote:
Turkish intelligence don't need to "crack" TLS; they just get Firefox to trust them by default, then do the normal MITM dance. I don't see why the NSA can't do that, too.
Thanks, Trent, that link is eye-opening!
My SSL fu isn't up to grokking how the cert would initially get onto his machine. Is the extra one sneaked in when firefox is pointed at a boobytrapped https page?
Erm, Firefox ignores the system certificate list and ships its own default list. AIUI, TUBITAK's key is in it, and trusted by default.
On 11.09.13 12:05, Trent W. Buck wrote:
Erm, Firefox ignores the system certificate list and ships its own default list. AIUI, TUBITAK's key is in it, and trusted by default.
Aahh: app.update.certs.requireBuiltin = True would seem to be unobtrusively pulling in the list you describe, IIUC, based just on https://bugzilla.mozilla.org/show_bug.cgi?id=651537 which says: » and depending on whether the cert is builtin or not app.update.cert.requireBuiltIn to false « Since also stumbling over some description of banks deploying SSL-inspecting proxies, though, I figure maybe this is doing nothing more than exercising my curiosity. Erik -- "Security is mostly a superstition. It does not exist in nature... Life is either a daring adventure or nothing." - Helen Keller
Quoting Trent W. Buck (trentbuck@gmail.com):
Turkish intelligence don't need to "crack" TLS; they just get Firefox to trust them by default, then do the normal MITM dance. I don't see why the NSA can't do that, too.
As Schneier often points out, NSA (like GCHQ, DSD, and others) don't attack strong crypto directly any time they have an option to cheat. ;-> (My own preference is to move away from relying on CA attestations as much as possible.)
G'day -
Given the media reports of the NSA using several supercomputers to crack SSL traffic (with some degree of success apparently) it may be that they don't have anything but brute force and possibly a few cryptology tricks, so far. (Depending on how much credence is to be given to anything heard in the media.)
Not much at all - everything we hear about NSA breaking RC4 thus far is speculation only. I remember back in earlier nineties ex-KGB boasted about being able to break any code in use on then-new Internet (US didn't allow export of 128-bit encryption to former Soviet Union at the time, but that wasn't a factor). It was sheer b.s. Those types just want us to believe that they have super powers. Regards Slav "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."
On 10 September 2013 10:48, Jason White <jason@jasonjgw.net> wrote:
Russell Coker <russell@coker.com.au> wrote:
Next if the NSA wanted to put some hostile code in the kernel then surely they would use a random gmail account to submit patches and not do anything bad under their own name.
Agreed. Further, if any government wanted to subvert cryptography they could do it by trying to sneak code into OpenSSL, NSS or GNUTLS - and the vulnerability would have to be subtle enough to escape notice by the maintainers.
Or the Debian maintainers could just "inadvertently" introduce the code themselves and no-one would notice for two years. http://article.gmane.org/gmane.linux.debian.security.announce/1614 T
Quoting Toby Corkindale (toby@dryft.net):
Or the Debian maintainers could just "inadvertently" introduce the code themselves and no-one would notice for two years. http://article.gmane.org/gmane.linux.debian.security.announce/1614
I'll cite my prior mailing list posts from elsewhere, to save time. (Please pardon the mild scatological reference.) Date: Tue, 10 Sep 2013 18:02:14 -0700 From: Rick Moen <rick@linuxmafia.com> To: pigdog@lists.pigdog.org Subject: Re: [Pigdog] spock attack on civilization Organization: If you lived here, you'd be $HOME already. X-Mas: Bah humbug. Quoting Trevor Johnson (trevor@jpj.net):
Rick Moen wrote:
Suborning corporate crypto was a pretty obvious step, I'd say.
Let's not forget CVE-2008-0166, a backdoor in Debian/Ubuntu that remained undiscovered for 20 months. Fun slideware: https://trailofbits.files.wordpress.com/2008/07/hope-08-openssl.pdf
Kurt Roeckx's good-faith effort to fix OpenSSL RNG spaghetti code[1] was not 'a trapdoor', but rather an unsuccessful effort to polish the turd that is OpenSSL.
I found this message interesting: http://www.mail-archive.com/freebsd-security@freebsd.org/msg04439.html
Well, yeah. That whole thread is spot-on. [1] http://www.peereboom.us/assl/assl/html/openssl.html Date: Tue, 10 Sep 2013 13:07:47 -0700 From: Rick Moen <rick@linuxmafia.com> To: linux-elitists@zgp.org Subject: Re: [linux-elitists] Surveillance Organization: If you lived here, you'd be $HOME already. X-Mas: Bah humbug. Quoting Eugen Leitl (eugen@leitl.org):
Consider all the crypto-related fubars in Debian. So far I chalked that up to incompetence, but now I do wonder. It would be good to do some forensics on the checkins that caused the regressions, and identify the culprits.
In the case of the much-ballyhooed inadvertent sabotaging of the RNG in the Debian/Ubuntu OpenSSL package[1], I think many commentators don't sufficiently appreciate just how bad the spaghetti-code problem in upstream OpenSSL is. Those who ascribe malice to Kurt Roeckx for his good-faith effort to fix truly messed-up C code are being, IMO, a bit idiotic and are missing the real problem entirely. [1] http://lwn.net/Articles/282038/
[If I just sent a half-message, sorry; I fat-fingered.] Rick Moen <rick@linuxmafia.com> writes:
Kurt Roeckx's good-faith effort to fix OpenSSL RNG spaghetti code[1] was not 'a trapdoor', but rather an unsuccessful effort to polish the turd that is OpenSSL.
See also https://wiki.debian.org/SSLkeys OpenSSL has other issues https://people.gnome.org/~markmc/openssl-and-the-gpl.html Makes me wonder why OpenLDAP has such a hard-on for it. GnuTLS's user interface is sure as shit a lot friendlier than OpenSSL's.
trentbuck@gmail.com (Trent W. Buck) writes:
Rick Moen <rick@linuxmafia.com> writes:
Kurt Roeckx's good-faith effort to fix OpenSSL RNG spaghetti code[1] was not 'a trapdoor', but rather an unsuccessful effort to polish the turd that is OpenSSL.
See also https://wiki.debian.org/SSLkeys
PS: for this reason, Debian's OpenSSH server has a CRL^W key revocation list. This is handy -- I blacklist ex-staff's known keys as defense- in-depth. Except CJ Watson wants to remove the patch, because (presumably) upstream weren't interested, and (totally understandably) maintaining distro-specific patches is a horrible thing and should be avoided where possible. I haven't had time to chat with him about it. :-( http://lists.debian.org/debian-ssh/2013/09/msg00014.html
On 2013-09-25 15:23, Trent W. Buck wrote: [...]
PS: for this reason, Debian's OpenSSH server has a CRL^W key revocation list. This is handy -- I blacklist ex-staff's known keys as defense- in-depth.
Except CJ Watson wants to remove the patch, because (presumably) upstream weren't interested, and (totally understandably) maintaining distro-specific patches is a horrible thing and should be avoided where possible. I haven't had time to chat with him about it. :-(
Upstream has its own implemenetaiton of these now: http://lwn.net/Articles/544640/, but I've no idea whether they pulled in Debian's implementation or wrote one from scratch. -- Regards, Matthew Cengia
On 25 September 2013 15:12, Trent W. Buck <trentbuck@gmail.com> wrote:
GnuTLS's user interface is sure as shit a lot friendlier than OpenSSL's.
libgcrypt, used by GnuTLS, has some big problems too: http://lists.debian.org/debian-devel/2010/03/msg00298.html Easy to fix, sure, however seems that upstream is not interested. (think there was a more recent thread somewhere, can't find it right now, doesn't contain anything new anyway) -- Brian May <brian@microcomaustralia.com.au>
Brian May wrote:
libgcrypt, used by GnuTLS, has some big problems too: http://lists.debian.org/debian-devel/2010/03/msg00298.html
Arthur de Jong's newer LDAP pam/nss library will avoid (2) indirectly by using a caching daemon, so that the LDAP bits are loaded into the setuid in the first place.
Robin Humble <rjh+luv@cita.utoronto.ca> writes:
if so then (Russell, I'm looking at you :-) why are you still confident selinux is a good thing and not just something designed to be so complex or so subtly buggy that the NSA can hide backdoors in it?
If you don't like SELinux, which LSM *do* you like? Are you advocating LSMless SUS DAC?
Android 4.3 has started using selinux. do we really trust android vendors to be on top of complex selinux configs or would we be better off with it err, off?
If you're running Frobozz distro and you don't trust Frobozz, Inc. to get security right, maybe you should pick a different distro.
Trent W. Buck <trentbuck@gmail.com> wrote:
Robin Humble <rjh+luv@cita.utoronto.ca> writes:
Android 4.3 has started using selinux. do we really trust android vendors to be on top of complex selinux configs or would we be better off with it err, off?
If you're running Frobozz distro and you don't trust Frobozz, Inc. to get security right, maybe you should pick a different distro.
Agreed. further, turning SELinux off is going to make security worse, because in that case no mandatory access controls are applied at all. Even if there's a bug in a policy that permits an operation which should not be allowed, the policy is still going to prevent numerous other potentially undesirable accesses.
Jason White <jason@jasonjgw.net> writes:
Trent W. Buck <trentbuck@gmail.com> wrote:
Robin Humble <rjh+luv@cita.utoronto.ca> writes:
Android 4.3 has started using selinux. do we really trust android vendors to be on top of complex selinux configs or would we be better off with it err, off?
If you're running Frobozz distro and you don't trust Frobozz, Inc. to get security right, maybe you should pick a different distro.
Agreed. further, turning SELinux off is going to make security worse, because in that case no mandatory access controls are applied at all. Even if there's a bug in a policy that permits an operation which should not be allowed, the policy is still going to prevent numerous other potentially undesirable accesses.
Having said that, if he's concerned about SELinux complexity, he should compile Linux without SELinux (rather that compiling it in and then disabling it) -- or run a simpler kernel entirely (e.g. OpenBSD's).
On Tue, Sep 10, 2013 at 12:45:19PM +1000, Trent W. Buck wrote:
Jason White <jason@jasonjgw.net> writes:
Trent W. Buck <trentbuck@gmail.com> wrote:
Robin Humble <rjh+luv@cita.utoronto.ca> writes:
Android 4.3 has started using selinux. do we really trust android vendors to be on top of complex selinux configs or would we be better off with it err, off? If you're running Frobozz distro and you don't trust Frobozz, Inc. to get security right, maybe you should pick a different distro.
exactly. do you trust samsung's coding abilities? http://www.androidpolice.com/2012/12/16/samsung-exynos-4-exploit-discovered-... people who fail at that level can't be trusted at all. yet plenty of folks still buy samsung phones... which is fine as long as you don't run samsung's buggy android version on it.
Having said that, if he's concerned about SELinux complexity, he should compile Linux without SELinux (rather that compiling it in and then disabling it) -- or run a simpler kernel entirely (e.g. OpenBSD's).
yup, sometimes I just don't compile it into the kernels. I see selinux as implementing bad practice. if daemons and apps aren't secure on their own then papering over that with a complex set of empirical behaviour checks isn't really going to help very much. in fact it's counter productive as it hides the real problems while adding complexity (ie. bugs) and a false sense of security. have there been many (any?) real world examples of selinux stopping attacks? I'm happy to hear success stories 'cos all I know at the moment is that it's caused a lot of admin grief and opened up at least one security hole. cheers, robin
Robin Humble <rjh+luv@cita.utoronto.ca> wrote:
I see selinux as implementing bad practice. if daemons and apps aren't secure on their own then papering over that with a complex set of empirical behaviour checks isn't really going to help very much. in fact it's counter productive as it hides the real problems while adding complexity (ie. bugs) and a false sense of security.
No, not at all. I think defence in depth is entirely valid and useful: limiting the damage caused by an exploit through mandatory access controls does not paper over the underlying problem or relieve software authors of the responsibility to write secure applications. It just acknowledges that bugs can occur, and when they do, we need extra layers of protection from the operating system. MAC is just one of those mechanisms, and SELinux a comprehensive implementation of it.
have there been many (any?) real world examples of selinux stopping attacks?
yes. red Hat has documented them. There was an article published in which Red Hat noted that a significant proportion of vulnerabilities in Red Hat Enterprise Linux were such that SELinux restrictions would provide real protection
On Tue, Sep 10, 2013 at 05:50:10PM +1000, Jason White wrote:
Robin Humble <rjh+luv@cita.utoronto.ca> wrote:
have there been many (any?) real world examples of selinux stopping attacks? yes. red Hat has documented them. There was an article published in which Red Hat noted that a significant proportion of vulnerabilities in Red Hat Enterprise Linux were such that SELinux restrictions would provide real protection
I can find only 2 hypothetical successful defences from about 2008. one samba bug and one obscure printer daemon. weighed up against the 1 vulnerability selinux caused, I guess that it's slightly ahead. that list isn't a ringing endorsement though... is there a better list somewhere? cheers, robin
G'day -
-----Original Message-----
I see selinux as implementing bad practice. if daemons and apps aren't secure on their own then papering over that with a complex set of empirical behaviour checks isn't really going to help very much.
If you don't exercise full control over applications then those checks might be the best control you've got.
have there been many (any?) real world examples of selinux stopping attacks?
You're asking for examples of non-events. Regards Slav "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."
participants (12)
-
Brian May -
Erik Christiansen -
Jason White -
Matthew Cengia -
Pidgorny, Slav (GEUS) -
Rick Moen -
Robin Humble -
Roger -
Russell Coker -
Toby Corkindale -
Trent W. Buck -
trentbuck＠gmail.com