OSNews

Indeed. I think its time, or somewhat past time, for *BSD, Linux, and other POSIX OSes to clearly distance themselves from MacOSX. When the malware tsunami hits Apple's platform, the effect (and the bad publicity) are going to be devastating.

Having a relatively small desktop market share, and having little malware affecting you does not mean that you would be as affected by it as the largest player if your market share were higher. But by the same token, it does not mean that you would not be affected so. It all depends upon how well prepared you are. And innocent and naive MacOS appears to be staggering into a bad part of town with its billfold halfway out of its back pocket and a target painted on its back.

Edited 2009-08-06 03:44 UTC

Snow Leopard will finally have the hardening and stack-protection tricks and the like that Vista and other Unixes do. Currently, although Leopard has some of these, they seem to be only halfway implemented with some exceptions (such as sandboxing daemons). These are some of the lesser-known features of Snow Leopard, Apple doesn't advertise them yet - probably because they don't want people to realize how insecure Leopard is by comparison.

I think that's about right!

I'm the only one who's touching my own MacBook but just to be safe I did install iAntiVirus and MacScan. When I used BeOS, I had "security through obscurity" because the common "teenager hacking software" doesn't understand BeOS. By now, the Mac OS has a large enough market share to be vulnerable. Very vulnerable.

It's funny, the guy who sold my Mac (that is, who did the administrative operations after I already had decided upon buying a Mac) actually had the nerve to claim Macintoshes are not vulnerable to viruses and such (even after Apple already admitted this to not be true). I'm sure this will happen all over, and I wonder how many lawsuits will be filed by people who were told the exact same thing but actually believed it.

I don't actually run an antivirus, viruses per-se aren't the main malware vector for Macs and they take up a lot of resources. Even on Windows, signature-based virus scanning is not very effective anymore even where viruses are a threat. What I do is harden my system as much as possible, by running an ipfw firewall (you can use a graphical front end to it like NoobProof or Waterroof) and little snitch, and using Firefox with the NoScript plug-in rather than Safari. (Which does more than just selectively filter javascript domains.)

I also run a program that scans versiontracker to see if my programs are up to date, as well of course as regularly running Apple Update for important things like Quicktime, Safari (even if you don't use Safari, quite a few other programs do! The situation's not as crazy as IE on Windows, but a lot of programs do use WebKit to display HTML and the like; as well as the Dashboard, etc...) and the OS updates.

If I was *really* concerned about security I'd also dump Mail.app in favor of Thunderbird or better yet Mutt or the like, but Mail.app is such a good mail program to use in Leopard that I can't bear to be without it's usability. Maybe I'll give Thunderbird a try when they finally release a more native-interface release version like Firefox 3 is.

yes the virus and malware storm which has been promised for years and has yet to arrive.

Yes no OS is perfect or immune, however thanks to its bsd unix underpinning it greatly reduces the surface of attack.

Not that much really. Malware today isn't about "rooting" machines, it's about reading private data and run botnets. Neither of those are really addressed by standard POSIX security measures.

Why would BSD want to distance itself from OSX, which itself is BSD

Actually, to be specific, OS X is not a member of the BSD family. It shares a userland with FreeBSD for the most part as well as most of the FreeBSD networking stack, but in many other ways (the kernel, drivers, launchd, etc) it is as different from a BSD--or any traditional UNIX for that matter--as it is possible to be. Being POSIX compatible it is certified as a UNIX, but underneath and around that there are a lot of differences.

Linux and BSD applications -- because this is an application problem -- have the very same bugs.

It's an easy bug to write. Just use a temporary file to store the file download, and it will by default be world readable.

That makes me wonder, why are temporary files created world readable by default? Having the /tmp folder be world readable and writeable makes perfect sense, but not the files within it. It strikes me that having the most restrictive permissions be the default on temp files would be the best way to go, and if a program for whatever reason needs other perms they could be specified. Either that, or have a user-specific temp folder with very restrictive perms and store any app-generated user-specific temp files there instead of where everyone can get at them.

It looks like they aren't necessarily. They're created with the user's default umask which seems to be world and group readable on many systems. Protecting the files is left up to the home directory permissions which are usually limited to user-only.

This permissive umask makes it easy for users to copy or link files into shared directories without using chmod after.

A good solution would be to set the user's TMPDIR environment variable to "/tmp/$USER" or "/home/$USER/tmp" and create this directory. Many functions will respect this variable. For the rest go through other tmpfile code and fix it up. Putting the directory in /tmp would be better if /tmp is mounted with special options such as being tmpfs.

Doesn't matter. If security is a concern, tmp files should not be created with the default umask but should be created with the most restrictive permissions possible unless explicitly specified otherwise. That simple.

I would modify that to just "tmp files should not be created with the default umask but should be created with the most restrictive permissions possible".

I think that the actual problem here is the "If security is a concern" part. That shouldn't be the exception. It should be the rule. It's hard to think of a time that a tmp file should be world readable.

A temporary pipe or socket, perhaps, in some specific cases. But not regular tmp files. On my Ubuntu box my umask is the standard 0022. I just ran /bin/mktemp and it properly created a file in /tmp with 600 permissions. I've just spot-checked my /tmp tree and there are no files with read or write permission for 'other'. (Which comes as no surprise.)

That Apple can't get this right is disgraceful, and rightly should make us wonder what other elementary blunders they are making elsewhere.

Perhaps someone with MacOSX would like to run:

find /tmp -type f -perm /o=r

and report their results. (Does MacOSX use /tmp?)

On Fedora /tmp files come out with the user's umask.

Ubuntu/Debian is probably the only Linux distro that does chmod 600 tmp file creation.

Fixes a problem whereby users can read files that other users are downloading in Safari. Howler!

Fixes a problem where users can still run programs using multi-touch gestures even when the screen is locked. Howler!

And lots of "maliciously crafted file" vulnerabilities fixed.


A lot of these, with the exception of the multitouch bug (my Mac mini thankfully doesn't have that one ;-) ) are in Safari, people concerned about security on OS X use Firefox with NoScript. :-) Safari will be noticably more secure in Snow Leopard, tabs will be sandboxed ah-lah Chrome.

Edited 2009-08-06 06:01 UTC

I know that OSX is a BSD certified Unix, but do people really use their Macs as multi-user computers? Maybe for rendering or something but for web browsing? Are they using VNC? Or was this just an obscure bug that didn't really need fixing because nobody uses OSX like that anyway?

That's interesting, for me it was 10.5.6 that had that problem and 10.5.7 which fixed it, even though it wasn't mentioned as a fix in 10.5.7's release notes. I haven't noticed it resurfacing in 10.5.8 at least not so far.

10.5.8 didn't fix it for me. :S

I don't understand why visual unity is considered such a plus. It just makes it harder to quickly pick out the right windows in Expose