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

OS X – Safe, yet horribly insecure

allthatiswrong.wordpress.com

Post reply on HN
Print view View original

111–120 of 134 posts

Re: OS X – Safe, yet horribly insecure

#111

Post by riffic »

xsive wrote: post #95
there wrote: post #86

Earlier quoted context omitted.

on a unix server, you have to be root to read everyone's data. on an os x laptop, you can be the logged-in user and read everyone's data. file permissions don't really mean much when everything of importance on the system is owned by one user (which is running dozens of applications with large attack surfaces). that's not really a criticism of mac os, because it's the same on a windows desktop. you need elevated priv…

> on a unix server, you have to be root to read everyone's data. > on an os x laptop, you can be the logged-in user and read everyone's data Shenanigans. Unless you have the password of the logged in user, you can't read stuff belonging to other users. Further, if the user in question does not have an Admin account, you're shit out of luck even if you do know their password.

reboot into single user mode, be root, read anything.

if you have physical access you can do anything

Re: OS X – Safe, yet horribly insecure

#112

Post by blub »

gonzo wrote: post #55
skybrian wrote: post #15

The author may have some good points, but this essay is so poorly organized that it's hard to tell what they are or put them into proper perspective. It's mostly a good argument for teaching essay-writing in school.

The piece is badly out of date when Lion ships next month.

The piece will be out of date, today it is accurate and interesting. Many security specialists have been saying the same thing.

Re: OS X – Safe, yet horribly insecure

#113

Post by __david__ »

danudey wrote: post #96
jbjohns wrote: post #35

Earlier quoted context omitted.

I'm sorry but this is a horrible argument. Granular security is critical to having a system that can actually be locked down. Which is why SELinux support is built into the kernel now.

And from my experience, most admins turn it off immediately rather than rewriting security policies so that Apache can access data outside of /var/www/, etc. Sure you could modify the policy, but it's enough of a hassle that no one I know has ever done it. Restrictive security that just gets in people's way is terrible security. Just like forcing people to change their password every 14 days results in people using t…

I'm glad I'm not the only one that hates SELinux. I find its setup to be super complicated yet all it ends up doing is stuff that I can do anyway with native unix permissions. As best I can tell it's a completely parallel world that is just there in case you mess up your normal permissions.

Re: OS X – Safe, yet horribly insecure

#114

Post by mveldthuis »

xsive wrote: post #95
there wrote: post #86

Earlier quoted context omitted.

on a unix server, you have to be root to read everyone's data. on an os x laptop, you can be the logged-in user and read everyone's data. file permissions don't really mean much when everything of importance on the system is owned by one user (which is running dozens of applications with large attack surfaces). that's not really a criticism of mac os, because it's the same on a windows desktop. you need elevated priv…

> on a unix server, you have to be root to read everyone's data. > on an os x laptop, you can be the logged-in user and read everyone's data Shenanigans. Unless you have the password of the logged in user, you can't read stuff belonging to other users. Further, if the user in question does not have an Admin account, you're shit out of luck even if you do know their password.

I think his point was that on a laptop, everyone is often just the one logged in user.

Re: OS X – Safe, yet horribly insecure

#115

Post by shinratdr »

seanp2k wrote: post #76
davidu wrote: post #37

This is actually just the tip of the iceberg for OS X vulnerabilities. On the enterprise side, it's much much worse. AFP is heinous. Their kerberos implementations are painful. They actually have checkboxes in OS X server config screens that say: "Prevent man in the middle attacks? Yes or No?"

We have some colocation clients who have a full cab of all XServes and Mac Pros (with OSX Server installed). One time, I asked what they run with all of that. They said "Ooh, we needed it to run Tomcat". Uhh.... I don't really understand the point of OSX Server beyond possibly render farms (for music / movies)

> I don't really understand the point of OSX Server beyond possibly render farms (for music / movies)

Small businesses, because they are very easy to manage.

More importantly though, Mac imaging. You can't run DeployStudio on anything but a Mac running OS X Server. So if you have more than 5-10 Macs to manage, having an OS X server around is a no brainer. It doesn't cost much and it makes managing & imaging Macs as simple or simpler than PCs. This is by far its most legitimate use.

Re: OS X – Safe, yet horribly insecure

#117

Post by X-Istence »

comex wrote: post #107
X-Istence wrote: post #100

Earlier quoted context omitted.

If you want to attach a debugger to a program in OS X you are required to be in a developer group, and it will ask you for a password. See: http://i.imgur.com/l6Ntz.png

Oh, is this new in Lion or something? I've never seen that prompt before. (But in any case, there are other options such as clever use of DYLD_INSERT_LIBRARIES.)

I'm running Snow Leopard.

Re: OS X – Safe, yet horribly insecure

#118

Post by lloeki »

jbjohns wrote: post #35
api wrote: post #28

"The Unix Design is significantly less granular than Windows..." That's why it's more secure. Complexity means you don't know what's going on. Complexity means you will forget something. Complexity means there's more likely to be a way to squeeze through, more likely to be a bug, more likely to be a little thing that is forgotten. This is also a problem with complex cryptographic APIs, overly complicated things like…

I'm sorry but this is a horrible argument. Granular security is critical to having a system that can actually be locked down. Which is why SELinux support is built into the kernel now.

The granularity actually can make it dangerous if it's an impediment to correctly designing such rights. Unix model has this advantage to be simple enough to accommodate most needs. A subtle misstep or two with ACLs can create a hard to notice path to escape, while since Unix rights are coarse, holes are generally quite coarse too.

Re: OS X – Safe, yet horribly insecure

#119

Post by tobylane »

rlpb wrote: post #27
X-Istence wrote: post #6

> The Unix Design is significantly less granular than that of Windows, not even having a basic ACL. The UNIX design came from a time when security was less of an issue and not taken as seriously as it did, and so does the job adequately. Windows NT (and later OSes) were actually designed with security in mind and this shows. This comparison doesn't even make sense, comparing a decades old UNIX design to a comparative…

Whether ACLs are present or not makes little difference. When a user is logged in, he either has access to do something or he doesn't. Only one line of that ACL really matters, and that's the same on a system with permission control but no ACLs (such as traditional Unix). If the user is able to escalate his privileges (whether with UAC or sudo, the OS doesn't matter) in order to install malware then he loses.

The recent malware entirely (as I understood) depended on the user putting their password into an OS prompt for permissions for the bad program. How can the OS make the line between that and something safe like Growl or Virtualbox?

Re: OS X – Safe, yet horribly insecure

#120

Post by hackermom »

gonzo wrote: post #104
hackermom wrote: post #79

Earlier quoted context omitted.

Your parentheses seem to imply that the OpenBSD team only started PF, and then let go of development, which isn't the case at all. The OpenBSD team is still the lead developer of PF, and FreeBSD sources changes from "The Source". To the best of my knowledge, there are no notable PF forks around from which the OpenBSD team can, or ever have sourced changes from, but I'd be happy to learn otherwise if you have any acco…

there is no "lead developer". Shall we discuss why pfSense is based on FreeBSD, not OpenBSD?

Because the developers of pfSense are FreeBSD users? I fail to see your point with that. And I beg to differ regarding the "no lead developer". Indulge yourself by looking at the OpenBSD changelog from release to release, year by year, and notice how every single change, minor and major, stems from there, and radiates out to, f.e., the PF port in FreeBSD.
Post reply on HN