Showing posts with label apple. Show all posts
Showing posts with label apple. Show all posts

Friday, November 04, 2011

On the Mac App Store and Sandbox Restrictions

Update: My friend, Chad, creator of Pear Note, has an interesting perspective that is much more in-depth than what I have written. While I don't agree with his conclusion, he is a successful full-time Mac developer where I have no Mac development experience. Also Chad has more SELinux background that I do.

There has been a lot of gnashing of teeth lately over Apple's forthcoming Sandbox restrictions on software sold through the Mac App Store. In the near future, applications sold through the Mac App Store will be confined by very restrictive security policies. These security policies will make it impossible for applications to do many of the things we are accustomed to applications being able to do, such as interact with other applications. Some have described this change, pejoratively, as the "iOS-ification" of the Mac. I think these people miss some important points.

I used to work at a company where most of my time involved developing either SELinux security policies (a technical mechanism that the operating system uses to restrict applications' behavior) or applications designed to be confined by SELinux policies. Unfortunately, although SELinux is extremely powerful, it isn't used to confine most Linux desktop applications. It exposes users to problems that are beyond their ability (or desire) to troubleshoot and fix. Having spent time working with under-appreciated access control mechanisms, I am really excited to see Sandboxes coming into the mainstream on an operating system known for its ease of use. This is a Good Thing for users.

SELinux is similar in some ways to Mac OS X's (and iOS's) Sandbox mechanism. These mechanisms enforce a system-wide security policy that cannot be overridden through traditional user-based file ownership and permissions. For example, an application executed by you shouldn't be allowed to change or delete all of your data (without asking you first) simply because you own the data. An unconfined application could be tricked into doing just that.

Apple has implemented a trusted process model in OS X Lion to handle risky behaviors. An application confined by a Sandbox profile might not be allowed to write its data to your hard disk. Instead, it has to send its data to a Lion-provided process whose job it is to write the data. That trusted process is only allowed to access data on the hard disk. It is not allowed to receive connections from other computers on the Internet. An attacker on the Internet would have to compromise not only your application, but also the trusted process in order to gain access to your data on your hard disk. Think of a building that requires entry through one door followed by another, and no single person has both keys. You have to co-opt both key holders to gain access.

Many things that applications normally do on their own will now have to be proxied through a trusted interface provided by Lion. Some things, such as adding cover art to iTunes albums, become impossible where no sanctioned interface is provided. In the near term, applications in the Mac App Store will become simpler and less capable because of this. I suspect that over time, though, Apple will provide more robust set of mechanisms that applications will be able to use to do more things. This way, applications will be able to do more on behalf of the user without introducing significant risk.

I like knowing that applications I install through the Mac App Store will be confined by a security mechanism that mitigates mistakes made by the developer. I'm happy with it as long as I can obtain applications from outside the App Store when I'm willing to assume more risk. You have choices. If you want an application that not only won't but can't eat your data (or syphon it off to the Russian mafia) get it from the Mac App Store. If you want an application that has more features--and more risk--buy it elsewhere from Chad's website.




Thursday, May 14, 2009

Spotlight does Math

I just discovered that Leopard's Spotlight does math. Try it. Bring up spotlight with ⌘+space. Then start typing something like
7pi*8.3 or
sqrt(2)
and the answer is the first search result.

This isn't quite a powerful as the Google calculator. It doesn't appear to do base conversion, and it doesn't let you copy the result for pasting into an application, but it seems handy nonetheless.

Wednesday, May 06, 2009

Mac OS X handy bash aliases

Here are a few handy aliases that I keep in my .bashrc in OS X:
alias cppwd='eval "echo `pwd` | tr -d \\\\n | pbcopy"'
This copies my current working directory to the OS X pasteboard so I can Cmd+V it into another terminal. Often I want several terminals open in the same directory at once.
alias burn='drutil burn -noverify'
This one lets me type
burn mydisc.iso
to burn an ISO disc image to CD or DVD without having to open Disk Utility.
And a variation:
alias vburn='drutil burn'
This does the same as the other but also does the disc verification step.

Saturday, January 10, 2009

OS X: How to detect whether you're on battery from the shell

Sometimes you need to determine programatically whether a computer is on battery or on AC. For example, I have a backup script that takes hourly snapshots of my home directory on my MacBook Pro (which I hopefully will post about at some point). However, I don't want the script to run if I'm on battery. Ideally, launchd, which kicks off the script, could give me this option, but I don't think it can. I'll have to let the script make the decision when it gets executed.

If I were writing the script for Linux, I'd have it look through /proc/acpi/ to check the state of the battery. There's no /proc in OS X. There is, however, a power management command, pmset.

If I run pmset -g while on AC, I get:

Currently drawing from 'AC Power'
-InternalBattery-0 100%; AC attached; not charging

If I run it while on battery, I get:

Currently drawing from 'Battery Power'
-InternalBattery-0 100%; discharging; (no estimate)

I simply have my script grep the output from pmset for "discharging":

checkBattery()
{
local ret=0;
if $PMSET -g batt | $GREP -q discharging;
then
ret=1;
fi
return $ret;
}

See the pmset(1) manpage for more info.