Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some Differences Between macOS and Common Unix Systems

dyx.name

Post reply on HN
Print view View original

61–70 of 82 posts

Re: Some Differences Between macOS and Common Unix Systems

#61

Post by ahartmetz »

1vuio0pswjnm7 wrote: post #58
yjftsjthsd-h wrote: post #3

> Some Differences between macOS and Common Unix Systems ...by which is meant, "Some differences between macOS, a certified Unix™, and systemd/Linux". Which is fine and valuable! But macOS is the most common Unix™, so the title as written is... entertaining.

macOS claims to be UNIX yet "XNU", the macOS kernel, is an abbreviation for "X is not UNIX". "Linux" refers to a kernel, inspired by Minix, which is an abbreviation for "mini-UNIX".

Linux is not based on Minix. What Linux does do is that it supports most everything required for POSIX compatibility.

Re: Some Differences Between macOS and Common Unix Systems

#62

Post by zepto »

smoldesu wrote: post #52
aborsy wrote: post #11

Not quite on this topic, but I have always felt Linux security seems lagging behind macOS. Linux seems lacking on sufficient sandboxing. I am also increasingly uncomfortable with so many repositories, FOOS on GitHub and users sudoing left and right. I am not sure if I am correct though.

MacOS is it's own security nightmare, it's just mangled and unrecognizable through so many layers of abstraction. Apple's understanding of security and privacy is fundamentally broken: they protect you against a boogyman, the idea of someone who wants to take your data for exploitative gain. In reality, the paradigm of computer security has completely changed. Apple had been leaking unencrypted user data to third par…

“a boogyman, the idea of someone who wants to take your data for exploitative gain”

Are you seriously claiming this isn’t a real threat?

Re: Some Differences Between macOS and Common Unix Systems

#63

Post by theamk »

bigbubba wrote: post #28
Brian_K_White wrote: post #18

Earlier quoted context omitted.

The main problem isn't really that it doesn't require sudo. If it installed as a user into your home dir, that would be fine. Changing a shared system-wide path or installing shared system-wide files owned by a user is so fundamentally borked that you should immediately reject anything offered by anyone who suggested to do that. But the masses of users who made it popular didn't know that and there were/are a lot of…

Can you spoonfeed me here? If ~/bin is in my PATH and is writable to my user, what is the problem with /usr/local/bin being the same on my personal computer with a single human user?

Base case (those are true AFAIK):

- /usr/local/bin is in a "system-wide" default PATH, (and it is even in front of /bin !)

- There is an important service, like Time Machine, which needs root access for important actions -- for example, to erase previous backups

- There could be a vulnerability in an application which gets data from the internet -- for the sake of example, let's say it is "foo file viewer". This can be exploited for code execution.

---

Case 1: Packages in ~/bin, /usr/local/bin is read-only:

A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents.

The malware has installed trojaned "~/bin/sudo" wrapper, but since the user does not use "sudo" that often, it did not have a change to get executed. And none of the system services look into user's "~/bin".

A week later, user notices that a document is encrypted. But the time machine backups are still OK. They reformat their machine, and then use time machine backup to restore the documents. Day is saved!

---

Case 2: Packages in usr/local/bin:

A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents.

The malware has installed a bunch of trojaned binaries, including "/usr/local/bin/touch" binary. Unfortunately, there is a LaunchDaemon which runs the script periodically which contains the line "touch /some/file". That is run as root, so in a short time, the malware gets root access. And it immediately used this access to disable time machine and delete all the backups.

A week later, user notices that a document is encrypted. And the time machine backups are gone, too. Oh no! the documents are lost unless they pay the ransom!

---

You might notice that some people may consider the scenario unrealistic: What if the user uses command line a lot, and is used to running "sudo"? What if a malware social engineers user by popping up a fake dialog asking for user password? Are there other privilege escalation methods? How often does this happen anyway?

You should make your own decisions, but hopefully you at least see what the people are concerned about.

Re: Some Differences Between macOS and Common Unix Systems

#64

Post by theamk »

segfaultbuserr wrote: post #29
Hackbraten wrote: post #14

I keep hearing that `sudo` insecurity argument everywhere. I think that argument is fundamentally wrong. In practice, a package manager that eschews `sudo` does not protect you any less than a package manager that works with `sudo`. If malware has obtained file system access, it’s already game over. The malicious code can now mess with your shell profile and fake the `sudo` command.

> fake the `sudo` command. I personally see that "su" and "sudo" are both fundamentally insecure. Compromising any sudoer, and root is essentially lost (e.g. keyloggers), thus the "wheel" group should only contain trusted accounts. It can be more secure if all root operations require a separate console, isolated from the rest of the world. For example, on historical Unix servers, it was a common practice to restrict…

I always thought that one of the big purposes of "sudo" is to prevent operator errors. For example, if I want to inspect the .deb file and accidentally type "dpkg -i" instead of "dpkg -I". Or if I am examining logs on a server, and mistype ">" and "It also helps a lot as a voluntary "logging" solution -- if you collect syslog on your servers, this can record which commands got run and why things got worse. It is not security solution, you'll have to make a "social convention" to never do "sudo su" or invoke ! in your editor, but it helps to detect accidental mistakes.

As for secure console, you can do this today! Make sure "k" is enabled in magic sysrq flags, and then you can switch to VT1 (alt-ctrl-f1) and invoke SAK with alt-sysrq-k. This'll kill everything on the current VT, and give you a clean login prompt which you can safely log into.

Finally, even with a single user, the privilege separation can help a lot with data protection. Just set up a backup process to run as root, into local directory where only root can write to. Then at least your data won't get deleted.

Re: Some Differences Between macOS and Common Unix Systems

#65

Post by theamk »

IshKebab wrote: post #43
Hackbraten wrote: post #14

I keep hearing that `sudo` insecurity argument everywhere. I think that argument is fundamentally wrong. In practice, a package manager that eschews `sudo` does not protect you any less than a package manager that works with `sudo`. If malware has obtained file system access, it’s already game over. The malicious code can now mess with your shell profile and fake the `sudo` command.

Yes the only way around that is to have sudo activate a Secure Attention Key. Windows has had that for many many years ("press ctrl-alt-del to continue") though they seem to have ditched it in Windows 10. Presumably users didn't know what it meant or why it was there and just did it when asked by anyone. I don't think it's really possible to make sudo use a SAK on Linux though because it requires tight integration of…

Are you saying you want "sudo" to use a a password entry mechanism which cannot be spoofed or intercepted? Something very similar to this is pretty easy on Linux.

If you are willing to pay a little, requiring Yuibikey press for sudo is supported [0].

If you don't want extra hardware, you can use "pam_exec" PAM method to read second factor (like PIN) from "/dev/input/by-id/...". This'll read from specific input device directly, bypassing GUI session or any other processes controlled by non-root user. Or use a "chvt" call instead, and you can have a secure display output too.

But while this will prevent "evil sudo" from capturing your password, it won't prevent "evil sudo" modifying the commands you want executed (the same problem exists with Windows SAK / Escalation prompt: you know you are approving some action, but it is not clear which action exactly).

I guess Linux has a unique advantage in that "sudo" is designed for user-readable commands -- so in many cases, confirming the command on un-tamperable output will be enough for safety (for example, "sudo apt install foo" will be safe this way). But you'd still want to make sure you are vigilant at all times -- if you have a habit of typing "curl ... | sudo sh", then no type of SAK process will save you from evil sudo.

[0] https://support.yubico.com/hc/en-us/articles/360016649099-Ub...

Re: Some Differences Between macOS and Common Unix Systems

#66

Post by segfaultbuserr »

theamk wrote: post #64
segfaultbuserr wrote: post #29

Earlier quoted context omitted.

> fake the `sudo` command. I personally see that "su" and "sudo" are both fundamentally insecure. Compromising any sudoer, and root is essentially lost (e.g. keyloggers), thus the "wheel" group should only contain trusted accounts. It can be more secure if all root operations require a separate console, isolated from the rest of the world. For example, on historical Unix servers, it was a common practice to restrict…

I always thought that one of the big purposes of "sudo" is to prevent operator errors. For example, if I want to inspect the .deb file and accidentally type "dpkg -i" instead of "dpkg -I". Or if I am examining logs on a server, and mistype ">" and " It also helps a lot as a voluntary "logging" solution -- if you collect syslog on your servers, this can record which commands got run and why things got worse. It is not…

> I always thought that one of the big purposes of "sudo" is to prevent operator errors.

Good point.

> As for secure console, you can do this today! Make sure "k" is enabled in magic sysrq flags

Thanks. I thought I was SysRq-literate as I frequently use the key for OOM killer, emergency sync and reboot. But it appears I was too ignorant to know the SAK. Just learned something new today.

Re: Some Differences Between macOS and Common Unix Systems

#67

Post by exmadscientist »

IshKebab wrote: post #43
Hackbraten wrote: post #14

I keep hearing that `sudo` insecurity argument everywhere. I think that argument is fundamentally wrong. In practice, a package manager that eschews `sudo` does not protect you any less than a package manager that works with `sudo`. If malware has obtained file system access, it’s already game over. The malicious code can now mess with your shell profile and fake the `sudo` command.

Yes the only way around that is to have sudo activate a Secure Attention Key. Windows has had that for many many years ("press ctrl-alt-del to continue") though they seem to have ditched it in Windows 10. Presumably users didn't know what it meant or why it was there and just did it when asked by anyone. I don't think it's really possible to make sudo use a SAK on Linux though because it requires tight integration of…

> though they seem to have ditched it in Windows 10

Nope, it's still there. It may require being joined to an AD Domain with the relevant setting toggled, though.

Re: Some Differences Between macOS and Common Unix Systems

#69

Post by cyberdelica »

ahartmetz wrote: post #61
1vuio0pswjnm7 wrote: post #58

Earlier quoted context omitted.

macOS claims to be UNIX yet "XNU", the macOS kernel, is an abbreviation for "X is not UNIX". "Linux" refers to a kernel, inspired by Minix, which is an abbreviation for "mini-UNIX".

Linux is not based on Minix. What Linux does do is that it supports most everything required for POSIX compatibility.

He wrote inspired by, not based on - which is true. Linus Torvalds was inspired by Minix, to write Linux.

Re: Some Differences Between macOS and Common Unix Systems

#70

Post by IshKebab »

theamk wrote: post #65
IshKebab wrote: post #43

Earlier quoted context omitted.

Yes the only way around that is to have sudo activate a Secure Attention Key. Windows has had that for many many years ("press ctrl-alt-del to continue") though they seem to have ditched it in Windows 10. Presumably users didn't know what it meant or why it was there and just did it when asked by anyone. I don't think it's really possible to make sudo use a SAK on Linux though because it requires tight integration of…

Are you saying you want "sudo" to use a a password entry mechanism which cannot be spoofed or intercepted? Something very similar to this is pretty easy on Linux. If you are willing to pay a little, requiring Yuibikey press for sudo is supported [0]. If you don't want extra hardware, you can use "pam_exec" PAM method to read second factor (like PIN) from "/dev/input/by-id/...". This'll read from specific input device…

A SAK is some action that only the kernel can detect. On Windows user-level programs cannot receive the ctrl-alt-del key sequence, so if you do that and something happens you can be sure you are interacting with the real authentication GUI, not a fake one.

I don't think any of your solutions provide that capability.

Post reply on HN