[milhous]

i'm sure at some point, everyone's had to repair their permissions at least once in their os x installs.

but i'm curious, shouldn't there be something in place to automatically "heal" these permissions so that users don't have to take such action? i'm not an expert on unix-based operating systems, but is this something just everyone using *nix has to deal with? os x's gone through three iterations, and i don't know if i can forsee 10.4 having such features either.

no trolling here, i'm just really curious. what causes these permissions to go out of whack in the first place? and what or who's authority are making those changes? thanks.

[Phil Sherry]

Originally posted by John Gruber @ Daring Fireball:
Mac OS X�s �Repair Permissions� feature is a bit of a misnomer; �Restore Permissions� or �Reset Permissions� would be a better name. �Repair� makes it sound as though files are broken if their permissions are affected by this process; that�s not the case. Files might have perfectly valid permissions but differ from what�s expected by the Repair Permissions process.

i like what he says.

[Angus_D]

Originally posted by milhous:
no trolling here, i'm just really curious. what causes these permissions to go out of whack in the first place? and what or who's authority are making those changes? thanks.

Normally badly written installers, or idiots that log in as root in the GUI and stuff.

I can't say I've really repaired permissions ever. I just did a verify and Internet Explorer had "incorrect permissions" (owner/group of me/staff rather than root/wheel - not a problem, I think I might just have a more recent version that I installed myself), as did several xcode projects in /Developer/Examples, things like that. None of it was really a problem at all.

This isn't a problem that most other *nix have because normally there the only people making changes are competent system administrators.

[Big Mac]

Repairing permissions quickly became positioned as a cure-all similar to rebuilding the desktop in OS 9, except it seems to me that rebuilding the desktop was a bit more useful in terms of system maintenance. Many people have taken permissions repair on as a ritual. It really is unnecessary unless a specific permissions problem is suspected.

[Angus_D]

Originally posted by Big Mac:
Repairing permissions quickly became positioned as a cure-all similar to rebuilding the desktop in OS 9, except it seems to me that rebuilding the desktop was a bit more useful in terms of system maintenance. Many people have taken permissions repair on as a ritual. It really is unnecessary unless a specific permissions problem is suspected.

Zap the PRAM!

[Millennium]

Use the following line of code in the Terminal:

Code:
sudo diskutil repairPermissions /

I'm not a wizard at doing cron jobs, but it should be possible to adapt this to something which could run as a regular maintenance script. The big problem is that repairing permissions requires root permissions (which is why the Disk Utility GUI requires a password), but I'd imagine that this could be arranged in a cron job.

[wataru]

Huh? I've never had to authenticate in order to repair permissions!

I have the following line in my /sw/etc/anacrontab:

Code:
  30        35       diskutil.perms    /usr/sbin/diskutil repairPermissions /

This makes the system repair permissions every 30 days at 10:35pm (the 35 is the delay in minutes from when anacron is run; I have anacron set to be run by cron every day at 10pm). This has been a decent solution for me. If you'd like to try it yourself, install anacron with fink.

[mcsjgs]

I, too, believe that there should be at least an option to automatically run repair permissions at user-defined times.

Atomic Bird, maker of Macaroni http://atomicbird.com/, would undoubtedly be unhappy if Apple did this, and I can see John Gruger's excellent point about Disk Utility's current system. If the Apple user experience is to be convenient yet Unix-powerful, something should be done to improve normal system maintenance for ordinary users. Soapbox off.

You can most definitely do this in cron (or anacron http://anacron.sourceforge.net/).

[Laurence]

You could also add a line to the system crontab (/private/etc/crontab) like the following...

0 13 * * * root diskutil repairPermissions /

I did this so every day at 1:00 PM the system would repair permissions under the root account. I don't know if this is the best way to do it, but I wanted it to run even if no user was logged in and this was the first thing I could come up with.

[Millennium]

Originally posted by Phil Sherry:
i like what he says.

All technically true, in that broken permissions on a file do not normally affect its contents. However, they can affect the behavior of the system itself, which is why I believe "repair" to be a proper term.

To be honest, I'd like to see a permissions check rolled into a full intrusion-detection system which could come as part of OSX. This is one of the few areas of security where both Apple and Microsoft are still pretty poor. Third-party systems such as HenWen exist, of course, but because they are not installed alongside the OS there is still a window of time -namely, between the time you install the OS and the time you install the IDS- that the system can be compromised and the IDS won't be able to catch it. Including the IDS as part of the system would eliminate that window.

In the case of checking permissions, of course, it's possible to automatically repair the system when problems are found, as we've already seen. Any alarm that comes from a system-file permissions problem should give an option to simply fix the permissions.

[kman42]

Isn't Tiger bringing a whole new type of permissions to the table? I thought I read that somewhere.

kman

[mcsjgs]

Originally posted by Millennium:
...Third-party systems such as HenWen exist, of course, but because they are not installed alongside the OS there is still a window of time -namely, between the time you install the OS and the time you install the IDS- that the system can be compromised and the IDS won't be able to catch it. Including the IDS as part of the system would eliminate that window.

Truer words were never spoken.

[Chuckit]

Originally posted by Millennium:
Third-party systems such as HenWen exist, of course, but because they are not installed alongside the OS there is still a window of time -namely, between the time you install the OS and the time you install the IDS- that the system can be compromised and the IDS won't be able to catch it.

If you're really all that concerned about intrusion, just don't connect the computer to the wider world until you have your security system in place.

[Angus_D]

Originally posted by Chuckit:
If you're really all that concerned about intrusion, just don't connect the computer to the wider world until you have your security system in place.

In these days of electronic distribution for everything, this creates a bit of a chicken-and-egg problem. How do you download Windows XP SP2 onto your brand new PC without connecting it to teh intarweb long enough to be compromised? Of course, you can download it in Linux or at a friend's or something, but these solutions are extra hassle and/or out of the reach of joe user.

[mcsjgs]

Originally posted by Chuckit:
If you're really all that concerned about intrusion, just don't connect the computer to the wider world until you have your security system in place.

You make a good point, and it is entirely valid for a fresh set-up. The problem arises if you think you have been compromised, and you think your backup may have been compromised as well. You want to eliminate any stay-behind scripts or programs and eliminate the source of the intrusion. I am a novice, but the boot sequence looks like a potential hole to me.

Edited: After looking at my own situation as hard as I know how, it looks far more likely that I let an intruder in the front door by downloading and evaluating too many shareware/freeware programs without carefully examing each and every one. You have to have some pretty hefty programming skills to be able to analyze every installer and package that programs come in these days. I don't have those skills. I now know better. Trusted sources and programs are now part of my computing routine. No more "hey, this looks like a neat idea!" It's sad because I greatly enjoyed looking at those types of programs. But it's just way too much hassle to have to do a clean install and re-install of all programs (not to mention data) when there is a problem.

[yukon]

seven posts in, and the rest of it (wataru has repeated the method)-
http://forums.macnn.com/showthread.p...hreadid=238491

I have anacron automatically repair permissions. Some say it's a troubleshooting measure, doing it automatically causes no harm though. It indeed "resets" permissions, but I don't change the permissions of any files but my own, only installers and such alter system permissions for me, so I'm not affected in a negative way when system permissions are "reset". This is all until www.bastille-linux.org (permissions-hardening program) gets a bit more work done on the OS X port. In the end, it reduces the possibilities for problems by one.

[Chuckit]

Originally posted by mcsjgs:
Edited: After looking at my own situation as hard as I know how, it looks far more likely that I let an intruder in the front door by downloading and evaluating too many shareware/freeware programs without carefully examing each and every one.

While I agree that you should be careful when using new programs, I find it kind of strange that you'd be the only person who's run this rogue program that compromises your security.

[mcsjgs]

Originally posted by Chuckit:
While I agree that you should be careful when using new programs, I find it kind of strange that you'd be the only person who's run this rogue program that compromises your security.

I agree, and I can't prove it did anything except change some permissions and unlock some lock icons in System Preferences. But it has happened enough over a 2 week period that it has me pretty spooked.

I jotted down some thoughts:

A recent problem with my system after a clean install got me to thinking about how it could have happened. Unhappily, I came up with this scenario for a trojan in OS X:

1. The trojan will be a system or menu utility, probably donationware or freeware, that has a legitimate reason to ask for an administrator password to either install or perform its function.

2. The trojan will hide behind a real program, albeit with only a few things to do: i.e. tell the weather, get a stock quote, or monitor some system function. The real program it hides behind will actually do what it says it will do, so there is no reason to discard or get rid of it. It will perform some useful function on a Mac.

3. If the trojan is well designed, it will have a legitimate reason to access the net, most likely a function to retrieve information of some kind that needs updating. This will bypass Little Snitch by seeming to perform its stated function while actually performing a secondary function as well. If the ultimate IP address is masked well enough for a secondary function, a "who is" search will reveal nothing of value.

4. If designed by a less-talented programmer, the trojan will simply do bad things to your system, i.e. erase or alter files or settings. If designed by a skilled programmer, the trojan will seek and store personal information, passwords and financial/business information which can be turned into monetary gain after being transmitted (encrypted?) to the net.

5. Checksumming all Unix executables into a database of some kind is useless. The trojan program will simply be added to the database when it is installed and won't change. Checksumming every file will yield little of analytical value since data is constantly changing. There are simply too many data files of varying types on most people's systems now to effectively monitor them all.

6. Unless the trojan is written poorly to require more CPU time or memory than seems reasonable, it won't show up easily in Activity Monitor, especially if it can latch onto a normal system call.

In short, an attack of this kind will be very difficult to defend against for the average, or even power user because the threat was invited in, and only sends data out through the firewall and/or router under seemingly innocuous circumstances. If it does system destruction, it will be found afterwards, too late to stop.

I hope I am wrong about this. The only way I can think of to avoid it is have some system of peer review of source code before programs are allowed to be distributed. I think this a most unlikely scenario in the highly competitive and communal environment of programming. The way it is now is "You downloads, and you takes your chances."

The only answer I can come up with to defend against it is to become a lot more conversant with Unix, Linux and BSD, Free, Open or otherwise. Without a good to very good working knowledge of the *nix world, it is impossible to detect this type of malicious programming. Which is not exactly what I signed up for on the Mac.

[Basilisk]

You make some interesting points...

I hope I am wrong about this.

You're only wrong to the extent that the scenario you describe is actually more complex than required. For example, use of an admin password isn't really necessary. The "interesting" bits of data on the machine are likely to be files owned by the user themselves (no admin password required).

The only way I can think of to avoid it is have some system of peer review of source code before programs are allowed to be distributed.

This is one of the standard arguments for open source security. The notion is that more eyeballs make it less likely malicious code could slip through.

I don't know that I accept that premise. In the Linux world (at least in its current developer/power-user form) its only vaguely plausible that most users make a security-conscious review of the code. The Mac market isn't nearly as oriented on user-as-developer so there's even less likelihood of review.

The only answer I can come up with to defend against it is to become a lot more conversant with Unix, Linux and BSD, Free, Open or otherwise. Without a good to very good working knowledge of the *nix world, it is impossible to detect this type of malicious programming.

Its axiomatic that the only truly safe computer is the one with the power unplugged. After that the next safest machine is the one that only has a well audited list of software on it. Neither option is probably practical for the average user who, let's face it, bought the computer to use it.

I don't want to discourage you, because I think learning the things you mention is a _good_ thing. Nevertheless, I'm fairly confident that the scenario you describe could be done with sufficient subtlety that it could be slipped past a large number of folks, even well-informed power UNIX users. There are folks on this forum I'm confident could write it in a manner I would never notice, and I'm pretty familiar with the MacOS X plumbing.

Which is not exactly what I signed up for on the Mac.

I think you overstate the risk. The analogy I used when I switched my mother-in-law is relevant, I'll repeat it here...

Every city has a "safe" part of town where the crime rate is lower. Frequently, this is also a more expensive place, but that's not necessarily the driving factor. It may be safer because of a great neighborhood watch, or because of a strong church community, or for any combination of a variety of other factors.

When folks move to the "safe" part of town there is no guarantee that they won't be a victim of crime. The low crime rate is just a historical average, there is no promise it won't change. For that matter, the crime rate is just lower, its rarely nonexistent. Bad things still happen, and sometimes, against the odds, they happen to people even in the safest areas. Living there is playing the odds, and it just happens that the odds are better in some places rather than others.

I've always thought of the Mac userbase as one of the safe parts of town. Its possible that there a super-trojan lurking in our future but it hasn't appeared yet. But when you compare that potential future risk against the known risks already present for Windows it seems pretty minor.

Now as to what factors make us safer, well, that's a long conversation, but I have a few ideas:

- Although not foolproof, the OS X security model does represent a reasonable compromise between usability and security. The initial "infection" of a user's machine does require a competent developer.

- The benign-appearing trojan you describe needs to be a useful application. This again raises the bar, to really be effective you have to be offering something that users actually want (and will keep running). This is hard, I speak from personal experience when I say that Mac users are a discriminating group. If you can produce an application that useful you may be better off selling it than trying to steal with it. Windows-style spyware hijacking to affiliate links is a possible exception to this case, but thus far other factors have prevented even this from happening.

- Macintosh news and software annoucements are filtered through a small pool of news organizations with active user communities. In these areas bad news travels fast and so a successful exploit requires you to fool nearly everyone right away.

- The most popular Macintosh software tends to come from a relatively small number of recognizable developers with longstanding reputations. For example, no one is afraid that Ambrosia (as an example) is going to turn evil on us.


So yes, be careful when you install new software, but remember that its not too dire. And when bad things do happen, I'm sure we'll hear about it here in the forums long before its likely to affect a large number of users.

Alex

[Millennium]

Originally posted by kman42:
Isn't Tiger bringing a whole new type of permissions to the table? I thought I read that somewhere.

There has been mention of Access Control Lists (ACLs), but I've only heard about them being used in Tiger Server. Of course, if they're in Server then it's likely that support will be in Client as well, without GUI. That seems to be how Apple does this sort of thing.

Either way, these systems don't replace the standard Unix permissions. They're a complementary system. Unix permissions -and therefore, most likely, the need to keep repairing them- will still be used alongside these.

[mcsjgs]

One last post on this, and I'll leave it alone since it's off topic. Basilisk makes some very good points. I don't think I am overreacting to this because I watch my computer very carefully. When you use the same machine every day for 17 months, you get used to how it does things. The lock icon in system preferences is very visible, and the locking option has been on in Security preference pane since Panther came out. You can not only see the icon change, you can hear it lock when you close it. So I doubt I am hallucinating when I check a pref like sharing, see it is locked, and come back in a couple of hours and find it is not. There could be other reasons: some system config that just does this, but I doubt it. The permissions thing is less easy. If I boot, there are always two permissions that need to be repaired:

We are using special permissions for the file or directory ./System/Library/Filesystems/cd9660.fs/cd9660.util. New permissions are 33261
Permissions differ on ., should be drwxrwxr-t , they are drwxrwxr-x
Owner and group corrected on .
Permissions corrected on .
The privileges have been verified or repaired on the selected volume

The first has always been so. The second has started only in the last month or so. If I repair permissions again, only the first shows up. Turn the machine off, boot up and two things need to be repaired. Simply put, this is not normal. Something is happening in either the shutdown or startup process that is changing a permission when it should not be doing so. Once again, is this a config fluke? Quite possibly. Maybe it started after 10.3.7. I am not sure. I should have been keeping a better log as the administrator.

Finally, the only thing that occurs to me that could be done is a global change log of every file changed every day that could be inspected every day. A huge pain, but maybe the only way to see if benignly or maliciously something is happening that should not be. Assuming you can figure out what the "normal" changes should be. Maybe after looking at such a log for a period of time, you could much more easily spot anomalies.

[wataru]

So check your /Library/StartupItems and /System/Library/StartupItems folders for suspicious items.

[mcsjgs]

Originally posted by wataru:
So check your /Library/StartupItems and /System/Library/StartupItems folders for suspicious items.

Already done, and nothing that should not be there. It's the correct place to start.

[jon l. dawson]

Originally posted by mcsjgs:

Finally, the only thing that occurs to me that could be done is a global change log of every file changed every day that could be inspected every day. A huge pain, but maybe the only way to see if benignly or maliciously something is happening that should not be. Assuming you can figure out what the "normal" changes should be. Maybe after looking at such a log for a period of time, you could much more easily spot anomalies.

I believe one of the BSDs does this as part of its nightly scripts. It scans the entire filesystem and emails any changes to the root account.

[mcsjgs]

Originally posted by jon l. dawson:
I believe one of the BSDs does this as part of its nightly scripts. It scans the entire filesystem and emails any changes to the root account.

Thank you. I am in the process of checking out FreeBSD and OpenBSD for a solution. I also realized that if I log all files in the daily incremental backup, I will get a list of all changed files. There were over 13,000 in today's log which appears to be maybe 20% higher than normal. So the checking part is a dificult task.

If you have a pointer to a BSD program with customizable parameters, it would be greatly appreciated.

[Laurence]

The situation mcsjgs describes has one flaw. Theoretically it would be possible, and actually quite easy for someone to write such an application, but they would have to post it to versiontracker, macupdate, etc. This hypothetical person would also have to have a web site to download the software from. This means that this person would be caught and jailed for his actions. Malicious coders usually want to avoid this and thus don't have web sites advertising their applications. If I came across a random file that I've never heard of on bittorrent, limewire, kazaa, etc, I would not even think to download it as I've never heard of it! You has to be a demand for a trojan program for it to work and creating that demand will leave a trail back to the person originating the software.

The only reason that the Mac will never become infested with viruses, trojans, etc is that they can't self replicate over a network due to the default settings of the OS.

[Millennium]

Originally posted by jon l. dawson:
I believe one of the BSDs does this as part of its nightly scripts. It scans the entire filesystem and emails any changes to the root account.

I wouldn't be surprised if OpenBSD did it. That kind of thing is an important part of a basic intrusion-detection system, just as I'm advocating that OSX integrate in some future release.

[Millennium]

Originally posted by Laurence:
The situation mcsjgs describes has one flaw. Theoretically it would be possible, and actually quite easy for someone to write such an application, but they would have to post it to versiontracker, macupdate, etc. This hypothetical person would also have to have a web site to download the software from.

Not necessarily. There are other means of distributing software. In particular, peer-to-peer filesharing networks have become popular. The warez scene has always been a fertile breeding ground for these things, and because of the anonymity offered by such networks it's very easy to get lost in the crowd.

This means that this person would be caught and jailed for his actions. Malicious coders usually want to avoid this and thus don't have web sites advertising their applications.

Indeed they don't, but they don't need these means. Smart malware writers have other ways of spreading software.

If I came across a random file that I've never heard of on bittorrent, limewire, kazaa, etc, I would not even think to download it as I've never heard of it!

That's very wise. Unfortunately, there are many thousands of users who are not as smart as you are, and these are the kinds of users on which malware preys.

You has to be a demand for a trojan program for it to work and creating that demand will leave a trail back to the person originating the software.

Most ways of creating demand will trace back to a person, but not all of them. All you have to do is drop a piece of malware into a place where people aren't very choosy about what they download, and eventually the problem will spread. This is why the warez scene has always been a breeding ground for these things; people tend to download the stuff en masse and then share it with others, often never even running most of the software they share. It's remarkable how persistent malware can be in that kind of environment, almost like a real disease.

The only reason that the Mac will never become infested with viruses, trojans, etc is that they can't self replicate over a network due to the default settings of the OS.

Viruses and trojans don't self-replicate over the network anyway; that's part of the definition. This may sound pedantic, but the point is that there are other ways for malware to spread. These methods are not common anymore, but they once were, and likely will become so again.

OSX's security can protect us from one specific form of malware which depends on kinds of flaws which OSX simply doesn't have. But not all malware exploits flaws in the operating system, and how does one protect against these?

[mcsjgs]

I dn't want to belabor the point (I say doing it) but there are other not-too-far-fetched scenarios:

1. Disaffected employees with poor source checking at the company (a one-shot, but possible damage).

2. A software company that is in decline and going out of business. The owners decide to to write malware, and take the money and run.

I am sure there are others.

[Dog Like Nature]

Yikes... let's all run to the hills!

Seriously though, if you're concerned about the sort of malware that steals information from you and sends it to some unknown entity there's two reasons (that come to mind) why you shouldn't be that concerned.

Firstly, and program that sends information needs to do so using system provided means. By this I mean there will be packets flowing out of your system that can be analyzed. It wouldn't be very long for such a program to be in the wild before people would see this happening and raise the alarm.

Secondly, get yourself a two-way firewall and block everything that you don't need. Of course, malware-generated packets can escape through the normally open range of ports, but this would still be covered by my first point, and would be easier to find because of the logging involved.

Bottom line is: Remain vigilant, practice safe computing, and relax!

[CharlesS]

Mac OS X�s �Repair Permissions� feature is a bit of a misnomer; �Restore Permissions� or �Reset Permissions� would be a better name. �Repair� makes it sound as though files are broken if their permissions are affected by this process; that�s not the case. Files might have perfectly valid permissions but differ from what�s expected by the Repair Permissions process.

Amen! People on here are way too eager to suggest Repair Permissions as the answer to every problem. Even worse are the ones who insist that you must run it every time you do a software update - both before and after! (How running Repair Permissions before a software update that runs as root anyway would make any difference at all is beyond me). Too many times someone posts a problem like this:

SomeGuy: Help, some of my files have the wrong icons!

CargoCultMember: Did you repair permissions both before AND after the last time you ran a software update? If not, it's YOUR FAULT!!!!!

[mcsjgs]

Originally posted by Dog Like Nature:
...Secondly, get yourself a two-way firewall and block everything that you don't need. Of course, malware-generated packets can escape through the normally open range of ports, but this would still be covered by my first point, and would be easier to find because of the logging involved.

Bottom line is: Remain vigilant, practice safe computing, and relax!

I think this is the ticket with an IDS that can actually analyze the outgoing packets and log the results. I'm playing catch-up here, but there seems to be some consensus about this in the literature.

[Basilisk]

I'm glad that you listed the specific problems, because it makes it much easier to (hopefully) put your mind at little more at ease.

The lock icon in system preferences is very visible, and the locking option has been on in Security preference pane since Panther came out. You can not only see the icon change, you can hear it lock when you close it. So I doubt I am hallucinating when I check a pref like sharing, see it is locked, and come back in a couple of hours and find it is not. There could be other reasons: some system config that just does this, but I doubt it.

Actually, that exactly how it works, System Prefs does "just do it". The lock can clear on its own if you are preauthorized. All that means you have the preference change right already stored in your credentials cache (and this can happen for a number of reasons).

Apple even addresses this specific example in their developer docs:

http://developer.apple.com/documenta...section_2.html

We are using special permissions for the file or directory ./System/Library/Filesystems/cd9660.fs/cd9660.util. New permissions are 33261

This is also harmless. I get this all the time (even on machines with clean installs I use for testing). This is an excellent example what the Daring Fireball article discussed. There's nothing wrong with the existing permissing. They aren't being repaired, they are being reset.

Permissions 33261 is 100755 in octal which is rwxr-xr-x. That's a perfectly reasonable (and secure) setting. As far as I know, the high bit (the leading 1) is meaningless in the POSIX standard, and gets thrown away by the filesystem, so it never gets applied correctly. I suspect that's why it always wants to change it.

So what's really happening? Fundamentally all reset permissions does is set the files permissions back to the mode byte stored for the file in the original package receipt. And that's where the problem is. Apparently the original Apple installer for that file (or at least some subsequent 10.3 update) has a bad mode byte for the file. Why doesn't Apple fix it? I don't know, but I suspect its just because its harmless and to fix it they would have to fix the original package receipt. It may be more trouble than its worth.

Permissions differ on ., should be drwxrwxr-t , they are drwxrwxr-x
Owner and group corrected on .
Permissions corrected on .

Again, harmless. The package receipt for the root directory wants the sticky mode bit set (the "t", making the directory append-only). As near as I can tell the mounter for the root filesystem clears this automatically. This is probably a good thing, you wouldn't really want your root filesystem append-only.


So, in short. I think you're OK. These are ghosts resulting for minor bugs in the repair permissions process. They are not indicative of any compromise on your machine.

Alex

[mcsjgs]

I can't tell you how much I appreciate such a reasoned, step-by-step analysis, and I really appreciate the Apple Developer article. Suspicious person that I am, I am not 100% sure that all anomalies are accounted for, but you sure put me over the 99% level. Thank you very much.