Mac OS X 10.6 (Snow Leopard) changes

log in

Advanced search

Message boards : BOINC Manager : Mac OS X 10.6 (Snow Leopard) changes

Author Message
Profile Ageless
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 29 Aug 05
Posts: 9075
Message 26995 - Posted: 2 Sep 2009, 8:53:22 UTC
Last modified: 2 Sep 2009, 14:00:25 UTC

Charlie Fenton, Macintosh BOINC developer wrote:
I've found another issue with Mac OS 10.6 Snow leopard that has necessitated additional changes in BOINC. I would appreciate feedback if anyone sees these changes as a problem.

Previously, Mac users without administrative privileges could run a limited version of the BOINC Manager. For example, attach, detach and reset projects were not permitted). They also could not directly access the contents of the BOINC Data directory with tools such as text editors, because of the sandbox security scheme described in http://boinc.berkeley.edu/sandbox.php.

Due to new restrictions in OS 10.6, I have made the following changes:

* If a non-admin user tries to run the Manager, they see an alert saying: "You currently are not authorized to manage the client. Please contact your administrator to add you to the 'boinc_master' user group."
BOINC then exits when they acknowledge the alert.

* Previously the installer added a login item for all users, so that the Manager would be started automatically when each user logged in. This is no longer done for non-admin users unless that user is a member of group boinc_master. If such a user has a login item from a previous install, it is removed.

* The installer asks if the BOINC screensaver should be selected for each user. If the answer is yes, then this is now done only for those users who can run the Manager.

Note that it is still possible to set up BOINC to run the Client as a daemon / service at all times, whether any user or no user is logged in. This is described at http://boinc.berkeley.edu/wiki/Tools_for_Mac_OS_X.

The disadvantages of these changes include:

* BOINC will no longer run if a non-admin user is logged in, unless the Client has been set up to run as a daemon / service.

* If the Client is running as a daemon / service, a non-admin user cannot suspend or snooze BOINC if it is interfering with his work.

I suspect that relatively few Macs are set up with any non-admin users.

For those interested in the gory technical details, read on:

The OS 10.6 Developer Release Notes at http://developer.apple.com/mac/library/releasenotes/Cocoa/AppKit.html say:
>As a security measure, SnowLeopard takes steps to prevent applications that use AppKit from running setuid or setgid.

The sandbox security scheme for BOINC on the Mac had the BOINC Manager running setgid boinc_master. This allowed the Manager to access the files it needs in the BOINC Data folder, such as the gui_rpc_auth.cfg file containing the password for communicating with the Client, even when run by a user who is not a member of group boinc_master..

Apparently there is no restriction as long as the logged-in user is also a member of group boinc_master. The Mac BOINC installer adds all users who have administrative privileges (i.e., who are members of group admin) to group boinc_master, so there is no problem with them running BOINC Manager under OS 10.6.

Of course, if the user running the Manager is a member of group boinc_master, then the setgid is not needed because the Manager would have permission to access the files anyway.

The purpose of using setgid was to allow non-admin users to run the Manager (though there is code in the Manager to limit the things they can do; for example, attach, detach and reset projects was not permitted.)

However, when a non-admin user ran BOINC Manager under Mac OS 10.6, the system displayed an authorization dialog requiring an admin user name and password. Othwewise it wouldn't run the Manager, due to the new restrictions on setgid applications.

Since the installer used to add a login item to start the Manager whenever these users logged in, this authorization dialog would appear every time they logged in under OS 10.6.

The AppKit framework implements the Cocoa APIs. The Manager uses AppKit for certain functions, and wxWidgets also requires it. The Client does not use AppKit, so the new restrictions on setuid and setgid do not apply to the Client.

The screensaver coordinator and default screensaver (boincscr) also use AppKit, but they do not run setuid or setgid, so the new restrictions do not apply to them either.

No other component of BOINC uses the AppKit framework.

--
Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer
Space Sciences Laboratory
UC Berkeley

meinsanjose
Send message
Joined: 5 Sep 09
Posts: 9
Message 27099 - Posted: 6 Sep 2009, 4:42:59 UTC - in response to Message 26995.

>I suspect that relatively few Macs are set up with any non-admin users.

Bad assumption. I advise all my clients to do just that as the single greatest way of dealing with malware attacks. So, you ought to deal with it, instead of rationalizing it away.

> Of course, if the user running the Manager is a member of group boinc_master, then the setgid is not needed because the Manager would have permission to access the files anyway.

You ought to call Apple support and ask how that is done on Snow Leopard. You will be surprised that it is either not possible or no one there knows. I suggest you modify your installation script, scan for all the users, display the list, ask the installer to select which users are included in group boinc_master.
____________

meinsanjose
Send message
Joined: 5 Sep 09
Posts: 9
Message 27105 - Posted: 6 Sep 2009, 15:26:00 UTC

I have a fix for group membership in boinc_master, to allow non administrator users access to BOINC's use of system space for data (A real Unix no no.). This will prevent BOINC from asking for the administrator's account name and password, each time the user attempts to start up BOINC.

Note: Your user's short name is the name under /users/<short name>.
CR = 'return key'

1) Logon as administrator
2) Open a "terminal" window, found in applications.
3) type "sudo dscl . -append /Groups/boinc_master GroupMembership <your user's short name> CR"
4) Respond to password prompt with administrator's password.
5) type "exit CR"
6) Exit terminal from the terminal menu bar at top of desktop.

The next time you logon as <user> the BOINC prompt will not appear.

Charlie Fenton
Volunteer moderator
Project developer
Send message
Joined: 17 Jul 06
Posts: 197
Message 27188 - Posted: 9 Sep 2009, 0:29:20 UTC - in response to Message 27105.


3) type "sudo dscl . -append /Groups/boinc_master GroupMembership CR"


I use the following:
"sudo dscl . -merge /groups/boinc_master users CR"

I'm not sure which is better.

I don't understand what you mean about "BOINC's use of system space for data." The BOINC Data is stored in /Library/Application Data/ which is the location Apple recommends for application data which is to be shared by all users on a single Mac.

Each user's personal settings for the Manager (column widths, Advanced View vs Simple View, etc.) are stored in that user's Preferences folder.
____________
Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

meinsanjose
Send message
Joined: 5 Sep 09
Posts: 9
Message 27194 - Posted: 9 Sep 2009, 4:55:16 UTC - in response to Message 27188.

In Unix any directory other than /Users/.... is reserved for root, the Unix kernal, or administrative functions. If any application is running, it should be running under some user. Therefore, data generated by that application would be stored, where it has permissions, under /Users/.... This conforms with Apple's development guidelines as well.
The idea that any user, regardless of permissions level, should be allowed to alter, over write, or generally mutilate a file or directory reserved for the O.S. is a Microsoft invention and a PC mentality. It is by Bill Gates has brought such havoc on the personal computing by opening the door for any malware that happens along, to destroy anything the "user" is allowed to touch.

meinsanjose
Send message
Joined: 5 Sep 09
Posts: 9
Message 27252 - Posted: 10 Sep 2009, 15:58:42 UTC - in response to Message 27194.

Now you have me stewing about the problem. Obviously, Snow Leopard took away 'setuid' to prevent violations of system space by rogue applications. So perhaps this might be a structural work around/change for future releases:

The Boinc installer should create a user called "boinc_master". Everything, except preferences that relate to how a particular user wants the engine to present itself on screen, resides under /users/boinc_master/library/application_support/boinc/data_blah_blah. Except screen saver objects, which I believe Apple has a special place for in system space.
The application has execute permissions for everyone. Administration (use 'getuid' to see who "me" is) (all admin accounts?) are automatically added to group "boinc_master" during installation. The account list is scanned for non administrative accounts. A file selection menu is presented during installation, asking for those accounts to be added to group "boinc_master". The phrasing would be; "Which account/users are authorized to run BOINC?".
As a last resort, code ought to be added to the applications, on start up, to check if the present user (getuid I think), is a member of group "boinc_master". If not, a dialog appears, requiring admin's name/password to add the present user to the group. This may or may not work, because I noticed that I required the "sudo" command to add myself, even when logged on as Administrator, indicating that only root had the authority to edit the group file.
____________

Charlie Fenton
Volunteer moderator
Project developer
Send message
Joined: 17 Jul 06
Posts: 197
Message 27264 - Posted: 10 Sep 2009, 21:23:20 UTC - in response to Message 27099.

Thank you for your suggestions.

I advise all my clients to do just that as the single greatest way of dealing with malware attacks.
This puzzles me a bit. If I understand, you are saying that you advise Mac users to always run as a user without administrator privileges. Could you explain how this prevents or nullifies malware attacks?


____________
Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

Curry
Send message
Joined: 11 Sep 09
Posts: 2
Message 27280 - Posted: 11 Sep 2009, 15:01:32 UTC - in response to Message 27188.

I'm interested in this thread as I also want to move my DOINC Data directory. My boot drive is a solid state disk so I minimize applications that make continuous writes to it. This is due to the nature of how SSDs work and the impact that built-in wear leveling has on disk performance after a period of time.

I find no way to set the data directory.
I created a link for the BOINC Data directory to point to a regular hard disk and BOInc won't start.
I couldn't find a configuration file that permitted manual editing of the data path.

Is there a resonable solution to moving the data directory?

Thanks,
Curry

Profile Ageless
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 29 Aug 05
Posts: 9075
Message 27281 - Posted: 11 Sep 2009, 15:29:54 UTC - in response to Message 27280.

Is there a resonable solution to moving the data directory?

See here.
____________
Jord

BOINC FAQs.

Curry
Send message
Joined: 11 Sep 09
Posts: 2
Message 27298 - Posted: 11 Sep 2009, 20:33:53 UTC - in response to Message 27281.

Thanks. That ended up doing the trick. Somehow I missed that in my search through the forum.

Curry

meinsanjose
Send message
Joined: 5 Sep 09
Posts: 9
Message 27321 - Posted: 12 Sep 2009, 16:04:43 UTC - in response to Message 27264.

Malware attacks:

Generally, they come in two forms. A rogue application is embedded in a web site or in email. The unsuspecting user opens/executes the program. Off it goes, identified as "user" with "user's" permissions, destroying whatever it can touch. Or, malware sneaks in through network administration.
Network admin is a black art and I don't have a lot to offer there.
On Windows PC's, there is no real differentiation between users, the system, files on the disk, or permissions to destroy just about anything. So, regardless of how malware gets on board, it can pretty much run amok. Mac OS is built on top of Unix. Unix, although not the best OS in the world, has a far superior notion of permissions and segregation of System space and User space on the disk. There are 3 levels. User, Groups that User belongs to, and Everyone. Root, or administrator, can go anywhere. But administrator is not really 'root' on Mac OS. If you take away a user/account's administrative abilities, you limit where that user may read/write to. On a Mac that is generally Mac HD/Users/<user>/....
Let's say a user gets infected (So far no one has tried because it is very difficult) with a virus, because they went to a web site or opened email. That malware has User's permissions. That means it can only read/write to the directory structure under /Users/<user>/ and nowhere else. If User protects their personal data, via something like a USB thin drive, then after an attack, that can easily be replaced.
But that is not the end of it. The Malware can not install itself anywhere but under /Users/<user>, without invoking the Mac OS protection dialog asking for the name of the administrator and password.
The User is immediately alerted to an attack. Neither can malware be added to the account start up list, even if saved under /Users/<user>, because the administrator controls accounts.
So, to be as safe as possible, I recommend to my clients that they have a separate Administrator account that they use to install programs, do admin, etc. Then any use of the computer to connect regularly to the outside world, such as browsing, email, or interactive applications should be operated under a new account, <their name>, with administrator privileges removed. That actually would be the account that was automatically created when a person first fired up their Mac and was interviewed by the start up script. So, Administrator must be created, via system preferences->accounts. Then one logs on as Administrator, opens accounts, opens <themselves>, and unchecks the 'admin privileges' box. Done.
While we are here, passwords. Most experts recommend separate passwords for different accounts. I realize we are all human and have limited memory, so I recommend one uncrackable super password for the important things, and whatever for everything else. So, use the same password for both User and Administrator. I suggest something you will never forget, but is not associated with you in any way on any document. For example a dead pet. I recommend upper/lower case letters and numbers. I would recommend special characters, but you will find most IT people are neanderthals and will not allow that. I.E. "mYluv4sQueEky" is pretty much uncrackable.
____________

Caden
Send message
Joined: 12 Sep 09
Posts: 4
Message 27329 - Posted: 12 Sep 2009, 21:16:10 UTC

Nooooo!! Great. I just upgraded to Snow Leopard and now BOINC really doesn't work properly anymore. I'm a non-admin user. I only use my admin user for things that require admin rights, such as installing software or updating the OS. I thought that was what was recommended? So BOINC isn't going to work easily this way anymore? I'm not about to start running as admin and I'm not about to let it be daemon and be unsuspendable. :-(

Oh, BTW, BOINC *used* to run as 64-bit app on Leopard. On Snow Leopard, it's running as 32-bit. Go figure!



Les Bayliss
Send message
Joined: 25 Nov 05
Posts: 852
Message 27330 - Posted: 12 Sep 2009, 21:25:04 UTC - in response to Message 27329.

So BOINC isn't going to work easily this way anymore?

This problem is "a work in progress". Please stay tuned for the next exiting instalment.

Speaking of instalments, Caden, did you read the first post here, or any of the other threads about Snow Leopard? Charlie has apparently 'fixed' the problem in the latest version, which I think is still alpha.
This thread has been diverted to discussing the correct way to provide the best security on Macs.

Profile Ageless
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 29 Aug 05
Posts: 9075
Message 27332 - Posted: 12 Sep 2009, 21:46:04 UTC - in response to Message 27329.

After you upgraded to Snow Leopard, you will have to reinstall BOINC.
____________
Jord

BOINC FAQs.

meinsanjose
Send message
Joined: 5 Sep 09
Posts: 9
Message 27352 - Posted: 13 Sep 2009, 18:07:10 UTC - in response to Message 27329.

Look above to the previous posts. I give a work around to stop the dialog asking for permissions from administrator every time <user> tries to launch BOINC. Plus, I used to use it as a screen saver too. Through BOINC preferences, as user, you can tell it to run only when the machine is idle. You can set screen saver to "none". It will run in the back ground while you are not there. But, for now, you won't see any evidence of progress until you look at the log.
The admin for BOINC promises a screen saver version soon. It seems to be in alpha mode right now.

Caden
Send message
Joined: 12 Sep 09
Posts: 4
Message 27365 - Posted: 13 Sep 2009, 23:59:11 UTC - in response to Message 27330.

[quote]Charlie has apparently 'fixed' the problem in the latest version, which I think is still alpha.
This thread has been diverted to discussing the correct way to provide the best security on Macs.


I probably misread the first post. I thought he was saying he was fixing the problem in a way that would really only work for folks running as admin on Macs, UNLESS folks like me (who insist on running non-admin for daily use) wanted to run it as a daemon service, which I don't want to do (I think of BOINC as an App that I can control). Anyway, I'll follow this and see what happens.

Charlie Fenton
Volunteer moderator
Project developer
Send message
Joined: 17 Jul 06
Posts: 197
Message 27381 - Posted: 14 Sep 2009, 19:38:19 UTC - in response to Message 27365.

You can easily enable it for non-admin users, as described in message 27105 and message 27188.
____________
Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

MrBungleBear
Send message
Joined: 22 Sep 09
Posts: 1
Message 27534 - Posted: 22 Sep 2009, 14:47:52 UTC
Last modified: 22 Sep 2009, 14:48:34 UTC

If you're installing to /Library anyway, I assume you require the admin user & password to install the thing... So only people who know the admin username and password can install BOINC anyway. Kinda sucks for the others, but them's the breaks. They're not supposed to install stuff willy-nilly anyway.

So, if you are installing as admin, though, you could create the boinc_master group at install time, scan for the list of users and display them, with checkboxes (and a select all & deselect all option), so that they could be added to that group. Those that get added will be able to run it without setgid and still control it. If anyone who can't asks for it, it is a simple task to add them to the group.

Or have I missed the point (it wouldn't be the first time, and won't be the last time!).

G>

meinsanjose
Send message
Joined: 5 Sep 09
Posts: 9
Message 27540 - Posted: 23 Sep 2009, 0:23:07 UTC - in response to Message 27534.

To MrBungleBear,

I covered the concept in 27252.

MeinSanJose

Charlie Fenton
Volunteer moderator
Project developer
Send message
Joined: 17 Jul 06
Posts: 197
Message 31705 - Posted: 22 Mar 2010, 10:44:40 UTC - in response to Message 27188.


3) type "sudo dscl . -append /Groups/boinc_master GroupMembership CR"

I use the following:
"sudo dscl . -merge /groups/boinc_master users CR"

With newer versions of BOINC, these commands will no longer do the trick. I've created a new AddRemove Usercommand-line utility just for this purpose. You can find it here. Be sure to give it your user's short name.
____________
Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

Message boards : BOINC Manager : Mac OS X 10.6 (Snow Leopard) changes


BOINC home page · Log in · Create account

Copyright © 2014 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.