found this to be salient, there's a lot of malice to be done in plain sight of an ignorant user:
Root access is only needed if you want to modify the system in some way so as to avoid detection. Doing so is by no means necessary however, and a lot of malware is more than happy to operate as a standard user, never once raising an elevation prompt and silently infection or copying files or sending out data or doing processing, or whatever malicious thing it may do.
OS X – Safe, yet horribly insecure
101–110 of 134 posts
Re: OS X – Safe, yet horribly insecure
#102Earlier 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.
> Shenanigans. Unless you have the password of the logged in user, you can't read stuff belonging to other users
Their home directory defaults to world readable, and the default umask is set so documents created are world readable, so you can read things in their home directories.
The Desktop, Documents, and so on directories are 700, so things in those should be unreadable.
Re: OS X – Safe, yet horribly insecure
#103Earlier quoted context omitted.
OpenBSD's pf? I highly doubt that Jordan Hubbard took the OpenBSD tree's variant. More likely it came directly from FreeBSD. (Yes, I know that 'pf' started on OpenBSD.)
what have freebsd contributed to pf?
don't get me stared on the lamefest that is OpenBSD
Re: OS X – Safe, yet horribly insecure
#104Earlier quoted context omitted.
OpenBSD's pf? I highly doubt that Jordan Hubbard took the OpenBSD tree's variant. More likely it came directly from FreeBSD. (Yes, I know that 'pf' started on OpenBSD.)
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?
Re: OS X – Safe, yet horribly insecure
#105> 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…
"[Unix permissions] were much better than what was available in Windows for the longest time"? Try DOS. Windows 1.0 - Me were never multi-user operating systems, which was largely the purpose of having permissions, until the world realised just what a mistake it is to have full, unguarded permission to your system files. MS's first multi-user OS was Windows NT in 1993, which shipped with ACLs.
Microsoft Xenix, 1980.
Re: OS X – Safe, yet horribly insecure
#106The whole article seems overly emotional and not objective at all. The only thing I agree with are that ASLR and DEP are not implemented as well as they could ( though I have not looked at it myself).
Re: OS X – Safe, yet horribly insecure
#107Earlier quoted context omitted.
However, you only need the password if you want to be root, and most of the stuff malware wants to do (including keylogging, which the article mentions; requiring root to intercept keyboards is only moderately useful if the regular user can gdb -p whatever app has the password field) does not require being root.
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.)
Re: OS X – Safe, yet horribly insecure
#108"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…
This is a good point. Getting ACLs to work - really and truly work in such a manner that they aren't overly restrictive or overly relaxed - is not trivial.
If you can attain security by trivial actions... that's a lot better than having to be really clever about it.
Re: OS X – Safe, yet horribly insecure
#109Earlier quoted context omitted.
If they did this (even as just an option), then there'd be an uproar about how they're incrementally making os x a completely closed system (a walled garden).
They've already done it. It's an option under parental controls.
Confirmed. I just checked in Snow Leopard. I would totally do this for clueless people, too.
Re: OS X – Safe, yet horribly insecure
#110All things said and done , one of the biggest flaws will be both Unix and Max giving a user the sense that both are secure and nothing can go wrong. That is the same reason Mac Defender worked.