Once I have bought a no-name tablet made in China that had malware installed in an unremovable 'browser' app. It was displaying ads on top of other apps, and was installing new apps onto tablet, and also restoring deleted apps, and also installing false copies of well known apps. It was rather ok because i bought it with the intention of tearing it apart, but still, the lesson for me was, NEVER enter sensitive personal data in devices of unknown origins.
Keep in mind that the devices from manufacturers which people usually "trust" more also have a similar, although less-blatantly-malicious, degree of disobeying you by default (silent automatic updates, unremovable system apps, etc.)
You could root it, and that would actually give you full control to delete/install/modify whatever you want.
I think the real lesson here is that if you do not have full control over a device, it is not truly yours and may disobey you.
They're not the same though; these problems need to be looked at through a combination of ability (to exploit) and motivation. Apple/Google isn't going to try and steal your identity, bank account info, or numerous other "small" things that some unknown and unaccountable company selling malware infected hardware could do.
It's like when people state that online voting should be safe because online banking is safe. I'm pretty sure if a nation state really wanted to steal a few grand from your (individual) bank account, they'd be able to do it. But it'd probably cost them more money/power in doing so then it's worth it.
> Apple/Google isn't going to try and steal your identity, bank account info, or numerous other "small" things
You can believe in that, and trust them, but you cannot prove that, unless you have access to the source of everything installed by Google/Apple, and source of third party apps, favored by Google/Apple. But, even if you're working for a government agency and have access to sources, it's still a monumental task to do, because of the volume of the sources. It's why we, Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd, which may take days just to read source.
Apple, Amazon, Google are not going to steal your credit card, identity, bank account info because you could sue them, and because consumer protections agencies would pursue them. The same is not true if you buy a no name tablet with malware pre loaded
They will not try to steal it because they have it. Check what analytics has the page where you make payments. Check your browser settings (passwords, credit card data).
> Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd
Nah, most Linux owners didn't care and the fact that the most distribution voted with their feet to switch should say enough. Also, full init script were not trivial.
Most people don't care about plumbing until it breaks and spews sewage water all across the apartment, after which they'll start having some pretty strong opinions about types of pipes. I didn't care about systemd until its default configuration deliberately broke emacs daemon and tmux, after which I had some pretty strong opinions about systemd.
At this point, every distribution disables that setting, but it shows that systemd's developers cannot be trusted to make reasonable defaults, and must be double-checked to avoid blatant foolishness.
Been using systemd for a very long time now and have had no issues. Had a very pleasant time setting up services to start on boot and such.
And you can't just pull out "Yeah but it might break sometime in the future" because it never has broken for me, and that same argument can be used against literally every thing in existence.
The vast majority of linux users have very positive experiences with systemd and it's cli tools are very good.
In this case, the only reason that it didn't break more widely is because the adults in the room overrode the default KillUserProcesses=yes at the distribution level.
This isn't an argument about whether something "might break in the future", as you so kindly put words into my mouth. This is an argument that I do not trust the systemd developers to make reasonable choices, as they have shown a willingness to break long-standing standards for benefits that are marginal at best.
KillUserProcesses=yes is quite a reasonable default for security though, as lingering processes after logout can be an issue on multi-user systems. For example it can be used as protection against fork bombs. I actually have no idea how Linux persisted for so long without something like that, it seems the long-standing standard here was not great. Rememeber that a lot of what a service manager has to do is decide what policies to set based on what security is provided by the kernel, so in some cases all they can do is provide an option and try to set that to the most secure default.
I tried to read those threads but I couldn't really gather much information, a lot of the rhetoric is pretty extreme and outrageous. I would suggest to avoid ad hominem comments about "adults in the room" and such, as it distracts from your argument. (more reading on this subject here http://www.paulgraham.com/disagree.html)
Multi-user systems are exactly the use case that makes KillUserProcesses=yes unsuitable as a default. Control groups are good for stability, because as you say, you can manage resource quotes, or kill an entire forkbomb. However, KillUserProcesses goes a step further, and also kills processes whenever there is a network failure. KillUserProcesses only makes sense in a single-user environment, where logging out is an active decision from the user.
Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. If SIGHUP is explicitly caught, then the process continues to live. With systemd defaults, logging out sends SIGKILL to processes, unless they they were started with "systemd-run --scope --user $PROCESS". In both cases, programs can persist, so there isn't a security benefit. However, one removes portability because it requires calling a systemd binary or linking against a systemd library, rather than being part of the POSIX standard.
The short-term benefit of KillUserProcesses=yes is that programs that erroneously request to be long-lived remain alive. The short-term drawback is that programs that correctly request to be long-lived are killed. The long-term benefit of KillUserProcesses=yes is nil, because programs can still erroneously request to be long-lived. The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits.
The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks. From their comments, requesting to be long-lived through the standard POSIX method is a hack, allowing the short-term drawbacks to be dismissed, and that a hard dependency on systemd libraries is not a long-term drawback.
With regard to my tone, perhaps I should have combined my two comments in this thread into a single one. The distributors being the adults in the room and overriding the systemd default was intended as a conclusion, to more fully describe an appropriate view toward the systemd developers. However, it appeared at the start of my second comment, and so I can see how it would appear as an attack rather than as a conclusion.
>KillUserProcesses only makes sense in a single-user environment, where logging out is an active decision from the user.
I can't agree, IMO processes left over after a network connection terminating could be considered a security hole. That's up to the sysadmin how to set it up. I certainly don't suggest getting into the habit of launching long running tasks in an ssh session, a remote sysadmin could already very easily end your processes if they find you AFK launching things on a sensitive machine. Systemd just gives some standard tools to do that.
>Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. [...] The short-term drawback is that programs that correctly request to be long-lived are killed.
This is incorrect, traditionally SIGHUP only means that the controlling terminal was disconnected. What you are describing is only correct for a single login shell with no sub-reapers, on a modern setup there are other things besides logging out that will send SIGHUP, such as for example if you run your program in an xterm and then close the window, or if you are operating within a sub-shell, etc. SIGHUP provides no way to differentiate those conditions, plus some programs will overload SIGHUP to be a "reload config" command, etc. SIGHUP is just not a reliable way to do it, I would not describe that as correctly requesting to be long-lived. SIGKILL is unfortunately the only method the kernel provides to do a reliable cleanup.
>The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits.
AFAIK there is no portable or simple way to do this, please enlighten me if I am missing something. Using daemon(3) and SIGHUP is not adequate here for reasons described above. Of course other init systems are free to create their own simplified implementation of systemd scopes, while skipping the Linux specific directives if they want. So it's not clear what your actual complaint is and what you mean the drawbacks are. Do they need help doing this? If so I would be happy to advise.
>in both cases, programs can persist, so there isn't a security benefit.
This is also incorrect, in the case of systemd scopes, you can further restrict the ability to create them with polkit or SELinux or similar. So you could make it so only tmux is allowed to start one for example. That would be one of the big benefits of having a real API for this versus just sending a signal and hoping the program is well behaved.
>The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks.
I don't think that is warranted, systemd developers can decide for themselves the trade offs of their program. The vitriol is not needed and is in fact likely to weaken the argument. In any case there are several other inits to choose from with their own set of strengths and drawbacks, I suggest focusing on what choices you have rather than agonizing over the small decisions of just one of them.
>Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd, which may take days just to read source.
Not sure I understand why you would cry about that, systemd is actually not a very complex project if you're used to low level C daemons. The most complicated part is the d-bus portions, but those are mostly a lot of boilerplate, and you should be understanding it anyway if you use a modern system with d-bus. Trivial initd and trivial shell scripts are also lacking in quite a bit of functionality compared to systemd, at least in my experience those would tend to grow until they became brittle and unmaintanable.
Online banking is safe because it is auditable and traceable. Voting has anonymity and chain-of-custody requirements that make doing it online extremely difficult.
> Apple/Google isn't going to try and steal your identity, bank account info, or numerous other "small" things that some unknown and unaccountable company selling malware infected hardware could do.
They all could do it, but are you aware of any manufacturer-installed malware or rootkits on a device that have? They don't steal your bank account info or impersonate you ever as far as I know, they make money off you in the same way every other company does.
If we can't show any instances, then it becomes difficult to find this materially worse than what other tech companies do. It becomes more like embarrassment from being owned by a obscure foreign company rather than a famous American one.
That account name is apt. Everybody -could- do it. Even your spouse, your best friend, your parents. They could all steal your shit. But for sanity’s sake a balance has to be struck between trust and paranoia.
The main difference, of course, being that your best friend is someone you could actually make having to face the legal consequences (and/or punch in the face).
These oversized American corporations are practically untouchable to the majority of people. They'll pay their laughable fines, pinky promises to better self-regulate for real this time, and move on. Leaving you in the dirt.
You're moving the goalpost from what Andrew and the person responding said though. The Chinese phone is acting just like a Samsung phone, only a tad bit worse. The Russian phone and the ones you mention are of course another story like you say but that's not what you were responding to, which is a valid point.
Of a well-known manufacturers, I noticed Xiaomi to do some real shit: it had an app preinstalled that displayed ads above other apps. But at least when I identified the culprit, it was possible to remove it completely and the problem went away.
I first ran into Xiaomi when I used a build of their MIUI rom on my Sony Ericsson X10 back in the day. It was amazingly better than default android (2.3/gingerbread era), so I wanted to keep using it.
Got a new phone at some point and tried it again, and they were on some real shit by then. All the default built-in programs for like, /music playing/ would force you through a Xiaomi Cloud sign up process just to play music /already on your phone/.
Granted, Google is now on the same shit; I found with my latest android they've removed all the basic apps for file browsing, music playing, and the like. Now only "Google Play" versions remain, that of course require a Google account.
I feel like the camera and calculator are the only non-play-required default apps left, but I won't be surprised if I find one day that the camera is somehow integrated into Google Photos, which will of course not open until you sign in.
I agree, this is basically how all tech companies work now. The only thing that holds it back is the outrage cycle, which
a) only turns its spotlight on companies above a certain size/visibility,
b) can be defeated with a large enough marketing/lobbying spend, and
c) can be waited out by companies with other lines of business that bring in profits, and
d) can be combated with cycles of withdrawing, quietly reintroducing, then withdrawing again, and reintroducing again until
d1.) media outlets get bored with it, or
d2.) all other companies in the same line start to do the same thing, a traditional way of price-fixing. Once this happens, the only way you'll be stopped is with legislation, because e.g. every TV has banner ad pop-ups from the manufacturer now.
> every TV has banner ad pop-ups from the manufacturer now.
AFAIK, Samsung and cheap Chinese brands (Vizio, TCL, and similar) do this.
Months ago I was between buying a LG or a Sony because they don't have bad reputation around this, and the LG I finally bought haven't any ad. Also, cookies, extra internet stuff, and the Alexa service can be deactivated separately without affecting apps like Netflix
Vizio, a US company, is the worst offender. These days it's hard to tell what is jingoism, or propaganda, and what is an honest mistake because a product is cheap
Before a certain Android version it was pretty common for Aliexpress sellers to plant unremovable ads, third-party stores, and god knows what else into the otherwise clean firmware, to be able to sell the phone with a discount. They usually didn't deny it, or even genuinely wondered - what's wrong with it? You bought it for a cheaper price after all, you should be happy, the seller is happy, everyone is, have a nice day sir. (a real conversation I had years ago)
It is the potential of hardware compromise that concerns me. Software can be wiped, but if the hardware itself contains backdoors, software can then be install at any time. Furthermore, given the global supply system, its so hard to confirm that any hardware is not compromised.
And always keep in mind that "you get what you paid for", and "if it's too good to be true, it probably is".
That makes it doubly shit that even premium products - TV's, laptops, etc - that aren't cheap or budget can come with ads, tracking and shitware pre-installed.
I'm thankful that my TV showed me separate licenses for things like advertising, tracking and voice control and wasn't difficult or annoying when I did not accept them.
