Live data from Hacker News

Some Differences Between macOS and Common Unix Systems

dyx.name

21–30 of 82 posts

Re: Some Differences Between macOS and Common Unix Systems

#21
post #20
post #19

Earlier quoted context omitted.

Some specific pieces of C++ support that Clang is missing: Edit: newer link: https://clang.llvm.org/cxx_status.html (older link, not applicable, was here) Cross compiling for some embedded architectures. Things like FORTRAN or Ada, calling routines built there from C (or vice versa), etc.

I don't know where you dug that up. That doc must be at least 10 years old. The clang that you get on an actual mac these days fully supports everything through C++17.

Thanks. Updated with a current link.

Re: Some Differences Between macOS and Common Unix Systems

#23
post #17

Is there any particular reason people would go out of their way to use gcc on macOS? It comes with clang/llvm, which seem adequate.

macOS does not come with llvm/clang, you have to download Xcode, which you can't do anonymously, you need to create an account with Apple. Ages ago, macOS did actually come with gcc.

Re: Some Differences Between macOS and Common Unix Systems

#24
post #8

Earlier quoted context omitted.

De facto or de jure? Linux isn't technically one, sure, but given that Linux is where the OS hot-shit is now (e.g. eBPF, although I think FreeBSD has the basics - no idea whether it got merged but I saw a student project) is it not fair to say it's where Unix would've been had things been different?

Both, I would say, particularly with the GNU’s Not UNIX userland. I don’t think it matters much, though, as you can have a great non-UNIX OS, which Linux definitely is. Also, we might forget it now, but in the past there were a lot of UNIX that were quite different in small and large ways. The differences between Linux and Darwin might be as great as the differences between SunOS and Xenix, or indeed NeXTSTEP, back i…

Outside of macOS, commercial Unix is basically dead. In the old days I used to see all sorts of systems. One company had Solaris 2.x, SunOS 4.x, Digital Unix, HPUX, AIX. Now you rarely see anything other than Linux, though I still know a couple of AIX shops that went all in on IBM hardware and still swear by it.

Like it or not, right or wrong, when people say "Unix" today, they mean Linux with GNU userland.

Re: Some Differences Between macOS and Common Unix Systems

#25
post #17

Is there any particular reason people would go out of their way to use gcc on macOS? It comes with clang/llvm, which seem adequate.

macOS does not come with llvm/clang, you have to download Xcode, which you can't do anonymously, you need to create an account with Apple. Ages ago, macOS did actually come with gcc.

You can install the toolchain with `xcode-select` which does not require an Apple ID.

Re: Some Differences Between macOS and Common Unix Systems

#27
post #13

> 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.

It’s a no-brainer Mac OS has more Unix heritage than Linux, but I don’t think using certification by the company that happens to own the name is the way to show that. I would think the BSDs have at least as much Unix heritage as macOS, but they aren’t certified (“Certified Unix” is a rare breed. https://www.opengroup.org/openbrand/register/ lists only 13 products) (Nitpick: it isn’t Unix™ , it’s UNIX® )

I don't think the 'certified unix' moniker counts for very much at all. It is uncertain that any non-corporately maintained Linux distro could qualify (per the opengroup page) as the kernel is developed outside of the distro.

The BSD's on the other hand could probably apply as they are one system (kernel and userland) with one governing body. But I doubt they really care to play the corporate standard mark game. They are UNIX and have always been so.

Re: Some Differences Between macOS and Common Unix Systems

#28

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.

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?

Re: Some Differences Between macOS and Common Unix Systems

#29

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 root logins to a physical terminal. But nowadays it's unfeasible. One solution for servers is disabling "su" and "sudo", and to allow root logins via pubkeys. This goes against the best practices, but can be more secure when it's used properly. Alternatively, create an "admin" account with sudo privilege, and guard it as carefully as your root account, because a sudoer is root.

On desktop, a solution can be using Intel ME/SGX/TXT and allowing it to take over your screen and keyboard to create a root shell - but it is proprietary, unauditable, and cannot be trusted. But it's not strictly needed - pure software can do something similar, e.g. you run two X servers on two separate VTs with two users, only the second user has access to a root shell. I guess better integration at the graphics server/system level is possible, you just need to be careful about GUI spoofing. For example, on Windows NT, pressing Control+Alt+Delete opens an unspoofable & isolated secure login screen - perhaps we should implement a secure root shell like that!

A more practical, although much less secure alternative is requiring 2FA, e.g. pressing a physical button on a USB token to sudo, it's something you can use today. But it cannot solve the problem of malicious command injections.

But on second thought, these problems are not really a priority in infosec - user applications are insecure in general, and user data is accessible without root anyway... As xkcd said, "they can read my mails, take my money, and impersonate me, but at least they cannot install device drivers without my permission..." So doing all of the works can be a total waste of time. Also, even with a separate root console, one must also have strong discipline not to execute anything or opening any complex binary data from another user (potentially compromised), which makes the whole idea fragile.

Finally QubesOS's approach is an innovative workaround and worth mentioning - normal and sensitive applications are running in separate VMs, providing strong isolation. Since both system and user applications are already isolated, it's not really that dangerous to be "root", so by default, everyone can sudo without any authentication. But if you are concerned about someone attacking supervisor via root, you can use Dom0 to 2FA authenticate sudo in an application VM without any extra hardware.

Re: Some Differences Between macOS and Common Unix Systems

#30
post #13

> 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.

It’s a no-brainer Mac OS has more Unix heritage than Linux, but I don’t think using certification by the company that happens to own the name is the way to show that. I would think the BSDs have at least as much Unix heritage as macOS, but they aren’t certified (“Certified Unix” is a rare breed. https://www.opengroup.org/openbrand/register/ lists only 13 products) (Nitpick: it isn’t Unix™ , it’s UNIX® )

Certified Unix just means you've paid SCO enough money. There are Linux-based Certified UNIX products: EulerOS and Inspur K-UX.
Post reply on HN