Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The PRISM revelations in particular made me realise that we can really only rely on Linux for security, since Apple, MS, Amazon and all the big tech companies are onboard with cooperating with the NSA. If you've read the way eg the CIA installs snooping software on Macs and PC's, they hide the Mac version in your hidden EFI boot volume, even from the factory.

It's enough to make you never trust them again.



Factory installed CIA snoop software on Macs is news to me, especially bearing in mind most of the factories are in Taiwan. Where can I find out more?

Also if the spyware is installed in firmware at the factory, how is Linux going to help you?


> especially bearing in mind most of the factories are in Taiwan

Zyxel, Asus, and other manufacturers of networking devices (with backdoors of course) are also there.

https://arstechnica.com/information-technology/2021/01/hacke...


OK, so some Taiwanese network device manufacturers have poor default account practices, news at 11:00. I'm not seeing the CIA connection.

Devices like this are used by the government and military contractors as well, and as you can see such vulnerabilities are trivial to detect so you can't count on the opposition finding out about it and using it. This one was picked up days after the firmware release. The smoking gun would be government and military admins secretly being advised by the CIA to close these security loopholes, so the government is protected but everyone else isn't. IMHO that would get Snowdened almost immediately. There's no way they'd keep a lid on that, there would just be too many people involved.

As with a lot of this conspiracy theory stuff, it only makes sense if you don't think about it too much. Once you actually start thinking through the consequences and practicalities, it doesn't hold together.


> poor default account practices

Understatement of the year. Secret account is exactly what people call "a backdoor".


Well I think it's mac specific software.

I learned about it from wikileaks. Eg https://wikileaks.org/ciav7p1/cms/space_2359301.html


That's iOS software, not Mac software, with the exception of info on some tools to install on a Mac to help hack iOS devices.


Yes that wasn't the precise link I apologise. They had details on the mac stuff too. If you look around. https://wikileaks.org/vault7/

https://www.pcworld.com/article/3184435/wikileaks-documents-...


Right so they have firmware malware and tools for infiltrating it into machines. That’s not a surprise. The extraordinary claim that I challenged was that this is being installed on Apple computers at the factories. So far as I can tel, there is no evidence for it.

This is like someone claiming it will rain next week and when asked how they know, they say they can prove it rained last week. That’s irrelevant. Yes I know they have firmware attacks. Where does the claim they are putting it on machines in the factory come from? How many times do I need to ask the same question?


I might have mistaken it for the evidence that they installed hacking tools on factory fresh iPhones, not macs.

https://wikileaks.org/vault7/

>"NightSkies 1.2" a "beacon/loader/implant tool" for the Apple iPhone. Noteworthy is that NightSkies had reached 1.2 by 2008, and is expressly designed to be physically installed onto factory fresh iPhones. i.e the CIA has been infecting the iPhone supply chain of its targets since at least 2008.


Factory fresh just means fresh from the factory, not necessarily in the factory. The attack targets phones in their manufactured state with the OS and vendor firmware installed. In other words it's not an attack that depends on end user software (Apps) being installed, or on user behaviour, or even on features of the mobile network.

By supply chain, when they say mail orders and other shipments, they just mean between the vendor and the customer. In this case the use of "supply chain" could be miss-understood, this is a post-factory attack which would be carried out in transit, probably at a US border.

We have seen that done before to shipments of devices such as computers and network gear that have been intercepted and hacked before delivery to a suspect, or a target organisation or country.

I don't think this can be reasonably construed as evidence for Apple conniving with the CIA. In fact I still don't think that would make any sense from a CIA perspective. The factories aren't even in the US. Apple employees aren't background checked or sworn agents, they're a potential security risk. Why involve them if you don't need to?


Alright then they probably aren't infected straight from the factory. However Apple is definitely collaborating with NSA as are other major US tech companies.


Security isn't the same as privacy. Linux desktop security is poor but its privacy can be okay.


If it's important for you and Linux security is not enough for you, consider using Qubes OS.


Why us it poor? (Genuinely asking).


No real push to use sandboxing or to limit access to personal information. Any app you install can do anything it wants with all of your data.


I know, it's amazing, isn't it? Just think of the amazing possibilities this new "general-purpose computing" could unlock!


Claiming that a lack of security is a feature, actually, is not a great strategy.


This definitely is a feature. You can use sandboxing if you want to. See kernel namespaces (used by Docker), Ubuntu's snaps, etc.

But breaking almost all software by default just because some incompetent users keep choosing to install malware is not a great strategy.


It isn't the dichotomy you set it up to be. macOS solved this without "breaking almost all software by default" using per-app, per-directory permissions for the file system, over and above the decades-old POSIX file modes model.

You're making excuses for the lack of security innovation on Linux workstations. They've fallen behind.


To be frank, Mac is not a model I would want to follow.

I am the sysadmin and owner of my machine, not Apple or some other organization. They have no business telling me what software I can and can't run, or what files that software can access.


They do neither.


They most definitely do, using their developer program. Look up Apple vs Epic for a case where they weaponized this.


You can run any software you want on macOS.

You can't publish any software you want on the App Store.


https://developer.apple.com/documentation/xcode/notarizing_m...

> Beginning in macOS 10.14.5, software signed with a new Developer ID certificate and all new or updated kernel extensions must be notarized to run. Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized

So, no. You need Apple's approval to be able to create software that can actually be ran by end-users even if you do not distribute using the App Store.


First, that is "software signed with a new Developer ID". You can just not sign software and it does not need to be notarised.

Second, notarisation is not an "approval". It is a malware scan.

The only thing that requires notarisation, which, again, is not "approval", is kernel extensions.


How can you notarize your software when apple has suspended your developer account? Would you not say that notarization requires you to have a developer account, which requires Apple's approval?


Can't you run apps on behalf of restricted users?


Via CLI you can, but GUI apps connect to your X server session, and then the fun begins - any application you allow to connect can essentially capture your keyboard, mouse, clipboard and a ton of other fun things,as there is no sandboxing applied between them. It's inherent in the design of the X protocol.

There are solutions that are intended to force the sandboxing by opening a new Xserver for every application, e.g. Firejail [0], but that comes with another set of interoperability problems.

Wayland was supposed to address some of these concerns, but it will only do so for applications that natively talk wayland protocol, not the ones that connect through x-protocol via xwayland

[0] https://firejail.wordpress.com/


I expected that Wayland isolates the applications by default, not just when they allow it.

So you might be interested in Qubes OS, which provides a very strong isolation through virtualization.


XWayland is essentially a translation layer consisting of Xserver and Wayland client [0]. Therefore it has all the same problems a normal Xserver has, which they do acknowledge:

> A Wayland compositor usually spawns only one Xwayland instance. This is because many X11 applications assume they can communicate with other X11 applications through the X server, and this requires a shared X server instance. This also means that Xwayland does not protect nor isolate X11 clients from each other, unless the Wayland compositor specifically chooses to break the X11 client intercommunications by spawning application specific Xwayland instances. X11 clients are naturally isolated from Wayland clients.

I use QubesOS, but it comes with its own set of problems as well.

[0] https://wayland.freedesktop.org/docs/html/ch05.html


That does not sound different from what Windows does. By default all programs running under the same user can access all windows of other applications (except UAC elevated ones). It's a relic from when OLE and Clipboard in Windows 3 just was (very simplified) a pointer to RAM.


The only reason it is worse with X11 is that it is an inherently networked protocol, so the same statements also apply to any remote connections you might allow to your X server. It also makes it somewhat easier to capture Xkb / Xinput events purely through API, without need for any elevation or excessive polling of the devices ("it just works").

That includes any systems you might have SSHed into with X forwarding enabled, as it automatically extends the trust there. Yes, your ssh client might try to enable X SECURITY extension (which clamps acesss to just the current window), but it is disabled by default or bypassed anyway by the users as that extension is known to crash quite a few programs.

Both are a product of their time when the prevailing approach was to trust the programs you run.


Not easily, no. Doing so is a big kludge, rather than being part of a system actually designed to offer useful security measures.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: