Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Hack Mac OS X With Installer Packages 194

Posted by kdawson from the why-not-to-run-as-admin dept.
nezmar writes, "MacGeekery has a short but insightful piece with examples on how to use a malformed Installer package (.pkg) on Mac OS X to 'insert user accounts with administrator rights and change root-owned system configuration or binary files without prompting the vast majority of Mac OS X users for a password of any kind.'" The article notes that this issue was brought up on the Apple Discussion Boards 6 weeks back and that it was noted there as a duplicate / known issue. It also gives as an example the installation of Parallels, the popular virtualization software, which uses the described technique, but not for nefarious purposes.
This discussion has been archived. No new comments can be posted.

Hack Mac OS X With Installer Packages More

Hack Mac OS X With Installer Packages

Comments Filter:

  • Well... (Score:5, Insightful)

    by Anonymous Coward on Saturday September 16, 2006 @01:40PM (#16121036)
    At the very least, until this is fixed, this is yet another reminder not to install things without knowing what they are.

    • Re: (Score:3, Insightful)

      by LiquidCoooled ( 634315 )
      People wouldn't install things if they don't know what they are, they obviously want to install [legitsoftware_name] on their system.
      However its important to make sure they trust the source they recieve the software from.

      As in the rest of life, use common sense and apply good judgement, stay away from the shady parts of the internet and you won't get stung. A reputable company would not risk the lawsuits with distributing known hacked packages.

      • Re: (Score:3, Funny)

        by Anonymous Coward
        A reputable company would not risk the lawsuits with distributing known hacked packages.
        What about the Sony roo... nevermind, missed the "reputable" part.

  • it still asked me for a password (Score:3, Insightful)

    by crashelite ( 882844 ) on Saturday September 16, 2006 @01:43PM (#16121047)
    i run as a admin account and it still asks me to use my password to gain access even the program they listed it asked for my password to be entered to install. so it still is all good for me... i dont install things that i dont know what they are in the first place so those kiddies trying to hack on a mac will have problems downloading their haxzor programs cause it will crash their mac and allow some one to access it no big. just one less user in the world that cant learn how to get into ppls computers oh well

    • Re: (Score:2)

      by Gilmoure ( 18428 )
      Yeah, but it's then one more machine, eating up bandwidth.

    • Re:it still asked me for a password (Score:5, Interesting)

      by Midnight Thunder ( 17205 ) on Saturday September 16, 2006 @02:36PM (#16121263) Homepage Journal
      This reminds of the suggestion that one security advisor provided. I think it was a story some time back here on slashdot.

      Basically the guy suggested that the authentication dialog should have a user customisable image (you would customise in control panel). That way when the password entry dialog appears the person would know whether the password request dialog was being provieded by the system, or being faked. The idea is that the is little chance in the rogue program working out the image the user used to authenticate password dialogs.

      It also makes us realise that validity of Microsoft providng the facility of signing packages. Although there are chances that you can have a faked certificate, this would help you limit yourself to a party with a valid certificate, if you so choose. The important point is that the certificate is used as an indication, not as a control mechanism.

      The truth is though, if you have enough careless users installing random garbage you increase the chances of your system getting 0wned, no matter what the OS. It is the same principal as in the real world where even if you have the best security system, if you have people leaving doors open, covering detectors because they make life inconvenient they are truely worthless.

      • Basically the guy suggested that the authentication dialog should have a user customisable image (you would customise in control panel). That way when the password entry dialog appears the person would know whether the password request dialog was being provieded by the system, or being faked. The idea is that the is little chance in the rogue program working out the image the user used to authenticate password dialogs.

        This would probably work really well until somebody figured out how to access the custom

      • Re:it still asked me for a password (Score:4, Informative)

        by Foolhardy ( 664051 ) <csmith32 @ g m a i l .com> on Saturday September 16, 2006 @04:16PM (#16121588)
        Actually, a better solution for authentication from the OS is a secure attention sequence (SAS), e.g. CTRL+ALT+DELETE on Windows NT or CTRL+ALT+PAUSE on Linux. The OS supersedes any application's attempt to trap this key sequence and puts the display into a mode that only shows OS sanctioned secure dialog boxes. On Windows (and XP with the welcome screen off) this is the "Windows Security" screen. This way, if you always enter the SAS before entering your password, you know that only the OS is receiving it. It helps to build the habit when the OS always asks you for the SAS before entering passwords.

        The new authorization dialog boxes in Vista are like this; this is the reason they take over the desktop. IIRC, you can hit CTRL+ALT+DELETE while one of these is up and you'll know its authentic because it'll stay there (if it weren't you'd switch to the "Windows Security" screen instead.)

        Of course, these are useless if the OS is already compromised, but the whole idea is to keep it from getting that far.

        • Re: (Score:3, Interesting)

          by Tony Hoyle ( 11698 )
          Of course nobody will do that. They'll see yet another dialog asking for their password and enter it blindly. Instant hacked system.
        • Whilst i'm not totally convinced on the secure attention sequence idea, lets hope that if Apple do implement it, they make sure it works.
          Unlike Windows where its not secure as you can intercept it.

          Have a look at SysInternals - Ctrl2Cap [sysinternals.com] utility for a working example.

          • Re: (Score:3, Interesting)

            by glesga_kiss ( 596639 )

            Whilst i'm not totally convinced on the secure attention sequence idea, lets hope that if Apple do implement it, they make sure it works. Unlike Windows where its not secure as you can intercept it.

            You can't intercept it without modifying the OS kernel. And if you've done that you already own the machine. ctrl-alt-delete is a very low level signal. This has been around since NT for login, it's nothing new. On linux you can customise what the combo does by modifying the inittab file.

    • Here is the FIX (Score:4, Informative)

      by goombah99 ( 560566 ) on Saturday September 16, 2006 @03:36PM (#16121467)
      I've known about this hole for about a year (yes I reported it to apple). The solution, which I use myself, is very simple. Do not run as sudo. I have two accouint. my everyday account and my sudo-user account. If you always run the installer as normal users then it will be forced to ask for a sudo-account name and password any time it needs to escalate privledges. There that's the fix.

      If you always run as a sudo user then you are exposed to this hole. It's not techincally a hole, but most people would consider it an unexpected behaviour. Most people figure that if they don't give the installer their password then it can't be installing anything priveldged. Wrong, it is possible. But you were installing so....you sort of got what you asked for, but obviously it's ripe for a trojan.

      The fix I give above simply forces the expected behaviour. If something wants to modify privledged files then it has to ask.

      Now here's the nice thing. Unlike linux and windows, it is a perfectly pleasant experience for a poweruser to run as anormal user on a mac. I'd die if I had to have this dual account system on linux, since not having super user privs is a pain. KDE and GNOME try to help you with some operation, but it's so inconsisten you cant make it work well.

      But on mac's it's nearly seemless. Anytime you need to authorize it pops up a window asking for a sudo account name. It's ubiquitous and there's virtually no time you need to be logged in as sudo-user. For extensive scrirpted or CLI coperations the terminal suffices to su to the sudo user. Now about once or twice a year, I find some situation where it is simpler to be in a GUI desktop as the sudo user. (one of those is fink-commander) For that there's fast user switching which lets me flip over to a logged in sudo GUI account instantly.

      It's painless.

      • WHY this is unexpected for macs (Score:5, Informative)

        by goombah99 ( 560566 ) on Saturday September 16, 2006 @04:13PM (#16121583)
        I'm going to reply to my own post because reading other comments I see that people don't grasp why this is an unexpected behaviour on a mac. It's a fairly normal behaviour on linux and Windows.

        On a mac, it's normally possible to install an application without requiring any super user privledges. On linux and Windows it's frequently impossible or at least quite hard (on linux you often have to fiddle with the make configuration, and it results normally in a crippled application.

        Here's one example. On a windows computer when you install something it has to have some way to get it's hooks into the OS. This might be as simple as notifying the OS of what extension/suffixes it can open or what services or filters it provides to other applications. This is done through the registry. And you need to be root to modify the registry. So you can't really install anything properly without giving your application the ability to write to the registry.

        And since there's no selective privledges that would say "well I trust you to only modify this part of the registry and no where else nor any other file, you basically pull your pants down around your ankles, close your eyes and pray there is no unsolicited finger up the butt every time you install. Linux is simmilar, since it propably wants to shove stuff in /bin and maybe overwrite somethings in /lib.

        On a mac, applications don't do that. Normally an entire application lives in a single folder with no stuff placed anywhere else. SO how does the application provide services? Well what happens is that the operating system will interorogate the Application when it is installed or when you boot or launch it the first time. Inside the application is a standard XML file info.plist that declares all sorts of things the OS might want to know about the application. And then the OS relays this to the other applications as serices that are available. This is how for example, the OS knows what applications can open what kind of documents.

        As a result, there is no need to unbuckle your jeans and grab your ankles when you do an install in most cases. And it's also easy to undo an application since the number of places it touches (usually just the application's folder and the library/preferences)

        Now I just said in most cases. Some applications do need privledges since they are going to make strong modifications. THis might be installing a start-up item, for example, or things that make intimate hardare interface modifications And for those when you run the installer script you naturally expect it to ask you for your password so it can escalate it's privs.

        And there is the problem. It turns out that the installer application on a mac, is a an application that can retain root privs after the first time you grant them (like says SETUID). To me this would seem unneccessary, but it does. And it turns out that if you are a sudo users, and if you have ever granted the installer elevated privs, then when it goes to install an application the requires elevated priv, it does not have to ask you for them! Now it also turns out that in most cases the applicaitons that are being installed can't know if a sudo user or a normal user is installing them so they automatically ask for the password. But they don't have to if you are sudo.

        So the fix is not to install as a sudo user. Then the installer can't get the elevated privs be default. And so the application is forced to ask for them if it needs them.

        Thus when your "make-a-smiley" application you got from gatorware asks for root during the install you have a chance to rethink if this might be a trojan.

        Thus the behaviour of the installer that blows past the authentication check is bothersome to mac users even though they are doing an install. On linux and windows doing an install normally is always done at root privs so the peril is always there.
        • The one directory thing only works for strictly GUI apps. If your app needs to install libraries in /usr/lib and put itself somewhere where the command line can see it like /bin the only option is give the installer root priviliges. Even installing a service that runs on startup needs a small shell script run as root. A lot of the stuff that apple ships does this.. try installing xcode without root privs.

          Don't get me started on the lack of an uninstaller (I've seen uninstall instructions for an app that
          • RedHat/Fedora:
            yum remove [appname]

            Debian/Ubuntu:
            apt-get remove [appname]

            AutoPackage (distro independent package system):
            package remove [appname]

            All do a clean uninstall.
            • If you absolutely need to install from source*, here is a good way to do it:

              ./configure --prefix=$HOME/apps
              make
              make install

              In .bashrc add:


              export PATH=$PATH:$HOME/apps
              export CFLAGS="$CFLAGS -L$HOME/apps/lib -I$HOME/apps/include"

              I haven't had that fail me. If you need to install something from source that needs to be accessible for other users, install it in /opt/[appname] and add the above things to /etc/bashrc. It works well.

              * Package repositories exist for a reason. Use them.

          • Re: (Score:3, Informative)

            by goombah99 ( 560566 )
            On macs you would not generally install into /usr/lib. Sometimes you would sure. But not normally. Even for pure CLI apps, in most cases you would have gotten those from a package manager like fink. And fink follows, partly, the apple style of being self contained. So it goes into /sw/bin. So what's the difference? well this means your bin's form other package managers and the system don't get stirred together. To delete just remove /sw. it's gone. You can also grant the permissions to change these

        • Re: (Score:2)

          by NMerriam ( 15122 )
          I'm actually sorry I poted another reply to this thread, since it meant I couldn't moderate you up. But I did want to thank you for explaining so clearly what is happening, why, and why it is unexpected.

        • Re:WHY this is unexpected for macs (Score:5, Informative)

          by drsmithy ( 35869 ) <drsmithyNO@SPAMgmail.com> on Saturday September 16, 2006 @07:23PM (#16122277)
          I'm going to reply to my own post because reading other comments I see that people don't grasp why this is an unexpected behaviour on a mac. It's a fairly normal behaviour on linux and Windows.

          According to the Apple documentation linked from TFA, if this behaviour is actually happening, then it is neither expected, nr proper, and is definitely a bug. How the article writer managed to arrive at the conclusion that Apple's documentation say it is correct and expected, I don't know.

          On a mac, it's normally possible to install an application without requiring any super user privledges. On linux and Windows it's frequently impossible or at least quite hard (on linux you often have to fiddle with the make configuration, and it results normally in a crippled application.

          On Windows this is an issue completely up to the application developer, who decides a) whether their installation procedures requires access to system areas, and/or b) whether they allow the user to specify where to install the applications (and/or c) if they bother to check the privilege level that the user has).

          On Linux, if you're compiling from source, it's a matter of passing --prefix=/some/path to 'configure'. WIth packages, it's a function of the package manager and subject to the same restrictions regarding whether or not the developer has done the right thing.

          OS X is *exactly* the same.

          Here's one example. On a windows computer when you install something it has to have some way to get it's hooks into the OS.

          No, it doesn't.

          This might be as simple as notifying the OS of what extension/suffixes it can open or what services or filters it provides to other applications. This is done through the registry. And you need to be root to modify the registry. So you can't really install anything properly without giving your application the ability to write to the registry.

          This is wrong.

          Firstly, you don't need to be "root" to write to the Registry (Windows has no "root" equivalent and access to the Registry is governed by the same types of ACLs that restrict filesystem access, applied on a per-Registry-key basis).

          Secondly, file associations and similar config data are stored in the per-user Registry hives which, of course, users are (typically) able to modify. The equivalents in OS X are all those XML config files hiding in your home directory (which, of course, you have permissions to modify - although access is not restricted at the same fine-grained level as it is to the Registry).

          And since there's no selective privledges that would say "well I trust you to only modify this part of the registry and no where else nor any other file, you basically pull your pants down around your ankles, close your eyes and pray there is no unsolicited finger up the butt every time you install. Linux is simmilar, since it propably wants to shove stuff in /bin and maybe overwrite somethings in /lib.

          There most certainly *is* the capability for such "selective pivileges" when accessing the Registry, and it is enforced. Linux (and unix in general - including OS X), however, lacks both the centralised repository to lock down access to such a degree and the fine-grained permissions system to actually do so, and is somewhat hampered by the fact "root" has no restrictions whatsoever (at least in typical configurations).

          As a result, there is no need to unbuckle your jeans and grab your ankles when you do an install in most cases. And it's also easy to undo an application since the number of places it touches (usually just the application's folder and the library/preferences)

          From a technical perspective, the situation in Windows (and Linux, to a less degree) is no different.

          And there is the problem. It turns out that the installer application on a mac, is a an application that can retain root privs after the first time you grant them (like says SETUID). To me this would seem unneccess

          • Re: (Score:3, Informative)

            by goombah99 ( 560566 )
            I'm going to reply to my own post because reading other comments I see that people don't grasp why this is an unexpected behaviour on a mac. It's a fairly normal behaviour on linux and Windows.

            According to the Apple documentation linked from TFA, if this behaviour is actually happening, then it is neither expected, nr proper, and is definitely a bug. How the article writer managed to arrive at the conclusion that Apple's documentation say it is correct and expected, I don't know.

            **perhaps if you are no

      • Re: (Score:2)

        by Ajehals ( 947354 )
        Im going to make a mild objection to one of your points - and that is your statement of:

        Unlike Linux and windows, it is a perfectly pleasant experience for a power user to run as anormal user on a mac. I'd die if I had to have this dual account system on Linux, since not having super user privs is a pain. KDE and GNOME try to help you with some operation, but it's so inconsistent you cant make it work well.

        Whilst I understand that in some circumstances it would not be workable to run as a non root user whi

        • Sure anyone can run from the command line as unprivledged because su is always there. It's no different on mac or linux.

          But trying to run in a gui as unprivledged in linux is a freakin nightmare. For example when you try this and you run a GUI program that need root (like say Gparted) then if you are truly Gnome or KDE will pop up a dialog asking for the root password. But that's asking for the root password, not asking for any user who has sudo. So if you are not root or have the root password then it

          • Re: (Score:2)

            by Ajehals ( 947354 )
            If you don't have access to the root password you really shouldn't be modifying the partitions on the system either :).

            If you are running a single user system or are administrating a home PC for a small number of users then its likely that you will know the root password. The whole point is that not everyone should be able to carryout these tasks (not everyone with an account should be on the sudo'ers list). If you just want partition info then there are a hosts of KDE and Gnome applications that will giv
            • If you don't have access to the root password you really shouldn't be modifying the partitions on the system either :).

              I saw the smiley, so I get your jist. But more seriously, that's sort of the point. If you are the super user but you run normally as root, it's a hassle on Linux to do some sys admin tasks without logging in as the super user's desktop. So naturally one tends to run as a sudo or super user as ones normal desktop.

              If you are running a single user system or are administrating a home

        • Re: (Score:2)

          by drsmithy ( 35869 )
          What kind of tasks are you performing on a regular basis that you cannot use Linux unless logged in as root?

          I think he is complaining because the graphical sudo programs in GNOME and KDE only work if your logged in user is in /etc/sudoers, they don't give you the opportunity to run as a user *not* in /etc/sudoers and specify a dedicated "sudoer" username/password when something needs to be run as root.

      • I've known about this hole for about a year (yes I reported it to apple). The solution, which I use myself, is very simple. Do not run as sudo. I have two accouint. my everyday account and my sudo-user account. If you always run the installer as normal users then it will be forced to ask for a sudo-account name and password any time it needs to escalate privledges. There that's the fix.

        That's a problem as well as a solution. Not many people setup two or more accounts, one for su and one or more account

        • Falcon, just a heads up, but unless things have changed linspire makes all users root unless otherwise told. yikes! watch out. and by the way creating a second user is not so much hard to do, per se, but just not something the average mac home user would ever think of doing. They ought to have a setup wizard that says, "Would you like to create a special accouunt for system maintanbinece separate from your daily user account (this is reccomended)?"

          • unless things have changed linspire makes all users root unless otherwise told. yikes! watch out.

            Before I saw the computers it was installed on, which I got one, I don't recall having heard of before. I got idea that it's by Lindows. What really got to me, and unfortunately many if not all computer manufacturers are now doing, it doesn't come with any printed manuals. And I like to RTFM. So I went to the Linspire website to print out what they have, and it didn't seem to me to be organized that well.

      • Re: (Score:2)

        by JadeNB ( 784349 )

        Now about once or twice a year, I find some situation where it is simpler to be in a GUI desktop as the sudo user. (one of those is fink-commander)

        By 'the sudo user' I assume you mean 'a sudoer' (i.e., by default, an administrator). Why do you need to be an administrator for Fink Commander? It prompts you for a sudoer's name and password just like any other application. For self-repair, you might need to enter the password twice; but I run it just fine as an ordinary user.

  • Ouch (Score:5, Informative)

    by bnenning ( 58349 ) on Saturday September 16, 2006 @01:44PM (#16121051)
    I knew it was weird when I installed Parallels a few months ago and it added several kernel extensions without a password prompt. This is a serious design flaw, and yet another reason for developers and users to avoid installer packages unless absolutely necessary.

    • Re: (Score:3, Informative)

      by drsmithy ( 35869 )
      I knew it was weird when I installed Parallels a few months ago and it added several kernel extensions without a password prompt. This is a serious design flaw, and yet another reason for developers and users to avoid installer packages unless absolutely necessary.

      According to the documentation linked from TFA, this behaviour is neither "proper", nor expected. Assuming the documentation is correct, it's not a design flaw, it's just a bug.

  • Hacking OS X? Hardly (Score:5, Insightful)

    by morgan_greywolf ( 835522 ) on Saturday September 16, 2006 @01:46PM (#16121056) Homepage Journal
    You still have to install the package as an admin user. Lots of tools on Linux create admin user accounts without prompting for a password when run as root. The Debian Advanced Package Tool (APT), in fact, is one of them. It's perfectly possible to create a .deb package that sets up admin user accounts without prompting, as long as you are running as root. Does that mean you can hack Debian or Ubuntu with .deb packages?
       
    • debian packages are cryptographically authenticated and come from a known-good source. Sure, someone on the Debian project could compromise my machine, but that's pretty obvious anyway.

      This is worse because any Joe on the Internet can create one of these packages. (Yes, any joe on the internet can create a debian package, but that's not a typical use case for apt users, whereas it's the only use case for Apple users.)
      • Since you have to be the author of the package being installed to make this "hack" work, I don't see *any* difference between the .deb problem, and the mac one. If I'm the author of a .deb, and I want to be nasty, why can't I crypographically sign the nasty version of the code ?

        Sure, people may (will?) soon find out I'm a bad guy, but the exact same situation is the case here.

        I don't see the usage difference you're talking about either - if I'm installing something I want/need, I'm going to do it on Debian
        • > Since you have to be the author of the package being installed to make this "hack" work, I don't see *any* difference between the .deb problem, and the mac one. If I'm the author of a .deb, and I want to be nasty, why can't I crypographically sign the nasty version of the code ?

          Debian packages are signed by the Debian project when they are approved for inclusion. If you have nasty bits in your package, you're not going to get it signed.
          • My point was that I have only had to use the installer on applications that come from Apple. Just like .debs come from the Debian project (well, I guess you *could* make your own up, but...)

            Maybe this is the difference - *I* think Apple and the debian project are equally trustworthy when it comes to installing applications into thier respective OS's. Perhaps you don't.

            Simon

        • I don't see *any* difference between the .deb problem, and the mac one. If I'm the author of a .deb, and I want to be nasty, why can't I crypographically sign the nasty version of the code ?

          The difference, such as it is, is that few debian/kubuntu/gentoo/etc users install any packages except from the "official" repositories. Anyway, I think that was the point my granparent was trying to make.

          However, the real reason why MacOs'ians are a lost case, securitywise, is that most of the source code is unavail

        • The previous siblings of this thread covered it:
          In OSX, there are two types of installer package things, admin ones and root ones. Running as an admin user (that is, a user that can become root-ish (like through sudo), if you install a root-level installer, you are prompted for your root password, yadda yadda. If you run an admin-level installer, no password is asked, and the vulnerability is here. Inside of that admin-level installer, root-level things can be done.

          So no. Your password is never asked, an

        • Re: (Score:2)

          by JadeNB ( 784349 )
          Some application authors think users are too dim to be trusted with copying the file themselves, so will set up a package whose sole function is automatically to move the application to /Applications. Naturally, this is wonderful for those of us who like to sort our applications into our own folders. Even if some library files need to be installed, they can often be put (if the user wants) in ~/Library instead of /Library; but Installer.app doesn't allow this.

          Darwinports -- which does need, or want, to

    • Re: (Score:2)

      by Coryoth ( 254751 )

      You still have to install the package as an admin user. Lots of tools on Linux create admin user accounts without prompting for a password when run as root.

      My understanding of the issue is that an admin user is simply someone on the sudoers list, and not actually root. This would akin to a .deb file that, when installed by a user on the sudoers list and not root, doesn't prompt for any password at all, but has root access none the less. This would seem to be an issue if I am, in fact, interpreting all of th

  • Let me get this straight ... (Score:3, Insightful)

    by khasim ( 1285 ) <brandioch.conner@gmail.com> on Saturday September 16, 2006 @01:46PM (#16121057)
    There exists a pretty significant interface problem with the Apple Installer program such that any package requesting admin access via the AdminAuthorization key, when run in an admin user account, is given full root-level access without providing the user with a password prompt during the install.

    So, when you're logged in as admin, and you install a package, that package can add whatever is in that package. Isn't that how it is supposed to work?

    I'm not seeing the problem here. Am I missing something?

    • Re: (Score:2, Flamebait)

      by Nutria ( 679911 )
      So, when you're logged in as admin, and you install a package, that package can add whatever is in that package. Isn't that how it is supposed to work?

      I'm not seeing the problem here. Am I missing something?

      I'm with you on this. Having Administrator power is supposed to let you do dangerous things.

      From the article:
      do not run as an admin user for daily activities.
      Well, duh!!! Only Windows users are that stupid, right?

    • Re: (Score:2)

      by mr_zorg ( 259994 )
      While you shouldn't be running as administrator for day to day use, this is still a problem. Just being an administrator on OS X is not equivalent to being root. It does, however, give you 'sudo su' privileges, which lets you execute tasks as root. Anytime an application needs to change root owned files (which all system files should be), it should be forced to pop up and ask you for your password (same as would happen if you ran 'sudo su root -c cmd' from terminal). The fact that it is possible for an
    • Here is how I see it. This could happen on most systems. If you are running as admin an installer will running under your profile may well add a user. I don't see this as an Apple only issue. However, with all the security concerns today it probably is worth a discussion. Should an installer be allowed to automatically create users? Genereally many apps may well require user accounts so I'd say they certainly should be allowed to automatically create users but perhaps require users to reenter admin pa

    • Re: (Score:2)

      by myrdred ( 597891 )
      You don't understand how the Admin account on OS X works (or is supposed to work, in this case).

      It is not the same as root nor as Admin accounts on Windows.

      On Mac OS X, the Admin account is like an in-between between regular user and root. That is, when you are logged on as an Admin, it generally allows you to do things that normal users can do, plus any permissions given specifically to Admins (these are not common). On the other hand, you _can_ also do anything else that you want, as root would, BUT befor

    • Re: (Score:2, Insightful)

      by ahknight ( 128958 ) *
      Many points, yes.

      1. The default user Apple makes is an admin. Non-computer-literate folks don't know this.
      2. Without providing a password, this gives an installer script root access.
      3. People will double-click anything.

      • Re: (Score:3, Funny)

        by spir0 ( 319821 )

        3. People will double-click anything.

        As an addendum to this I'd like to add that most users will double click on anything, and when nothing happens, they will continue to double click until something either does happen or their mouse finger falls off, or their computer dies. Whichever happens first.

    • Even as an admin, you are always prompted to enter your password whenever a process is trying to change system files. For those familiar with Debian-based linux, that means that an "admin user" is a regular user who is a sudoer, whereas a non-admin is a regular user who is not a sudoer.

      The big deal here is that the additional password prompt---which signals the fact that you are changing system files---allegedly never happened under the conditions described here.
    • An old idea around for some time was to design an install user that is similar to root but with limitations then limit root's power.

      The extras depends on the system and how far you'd want to go to protect the system.
      root could lose some access (ie: read-only OS.)
      the install user would be limited to mostly disk related activities. This is just 1 example of the features that could be possible by singling out the whole process of system level software installation.

    • Re: (Score:3, Interesting)

      by rthille ( 8526 )
      The point you're missing (though I'm not sure this is accurate, I just got it from the article) is that an 'admin user' on OS-X is basically the same as someone who's in the sudoers list or in the wheel group on Unix. You _may_ access root, but not everything you do is as root. This is like the ability to run 'su' or 'sudo' and not type your password to become root. If that were true on linux, then any untrusted program you ran as 'joeuser' could become root without the user's knowledge, just by invoking

  • So, in summation (Score:5, Insightful)

    by banky ( 9941 ) <gregg AT neurobashing DOT com> on Saturday September 16, 2006 @01:46PM (#16121058) Homepage Journal
    1. If you're sitting at the box, you might be able to 0wnz0r it. Same as for Linux, BSD, and Windows.
    2. Regular folk should only install software from reasonably trusted sources.

    I would assume that second point would be clear, given 10 years of watching Windows users open every last attachment that arrives in their inbox, while we sit at our Macs and laugh, but something tells me, probably not.
    • I partially agree with what you said, but this is a serious issue that needs to be fixed. Optimally, even the king of all idiots and all of his idiot horses and all of his idiot men should not be able to "0wnz0r" his computer through idiocy.

    • Re: (Score:2)

      by lpq ( 583377 )

      2. Regular folk should only install software from reasonably trusted sources.

      Therein lies the rub. How many packages under MacOS or Windows can you install fromsources that you trust?

      I asked a Windows firewall developer who was developing a firewall based on BSD sources. Yet when I wanted to try the product, the developer was all "*clueless*" about why I would would need the sources to run their "special", "free", firewall product [coresecurity.com]. The fact that they didn't, even, understand the need to compile from so

  • Not a "solution" per se, but (Score:5, Informative)

    by 93 Escort Wagon ( 326346 ) on Saturday September 16, 2006 @02:03PM (#16121120)
    It is hard to get most Mac users to not use an admin account, because if you're the only user it will be admin by default.

    I've tried to explain to other Mac users that running as an admin by default is bad, and they always come back with "but you always get a pop-up asking for your username and password anyway, so you always know something is up". Unix-heads know this is wrong, but Mac users as a whole are as uninformed as your average Windows user.

    The silly thing is OS X makes it absurdly easy to run as a non-admin. Just create a second account, make it an administrator, and then remove that privilege from your own account! If some task needs admin privileges, OS X will automatically prompt you for an admin account login - you don't even need to think about it beforehand (unlike XP's less-than-perfect "Run as..." solution). If an application tries to do something admin-y without asking you to authenticate as an admin, it will fail.

    The only time this is ever a hassle is if you're installing one of a handful of software packages that doesn't use the OS X security framework. Adobe is the most egregious offender in this regard - they even require that the first time you launch a number of their programs (right after install in other words), it has to be done as an administrator. There's no good reason for them to do this, but it's part of their "We can't stop the pirates, but we can darn well make it a pain for law-abiding customers" initiative.

    • Re: (Score:2)

      by MoneyT ( 548795 )
      So instead of having to type their password to destroy their machine, they have to type a username and password. How does this solve the problem at hand?
      • "So instead of having to type their password to destroy their machine, they have to type a username and password. How does this solve the problem at hand?"

        Read the discussion board thread linked from the story (I know, this is Slashdot, but...). The issue is that the user didn't have to type in ANYTHING, period. It wasn't that some extra nefarious stuff happened during an installation; he was able to install the php5 package without being prompted for a log in at all. Just being an admin was enough.

        The wide
  • from TFA:
    Read my previous guide to securing Mac OS X and do not run as an admin user for daily activities.
    Moreover, if you must run as the administrator, do not install packages from non-reputable sources without cracking open the package

    Well, thank you, Captain Obvious!

  • "Installs" are bad (Score:4, Interesting)

    by Animats ( 122034 ) on Saturday September 16, 2006 @02:19PM (#16121188) Homepage

    One of the great features of the original MacOS was that it didn't have "installation". You put an application somewhere, the Finder found it, and you could launch it. If you wanted to delete it, you deleted it, and it disappeared. Maybe once in a while you had to rebuild the desktop to update the derived info that made this work.

    But now, Apple has "installation", where install programs put stuff all over the place, and maybe change the state of the system. Just like Windows. Big step backwards.

    • One of the great features of the original MacOS was that it didn't have "installation". You put an application somewhere, the Finder found it, and you could launch it. If you wanted to delete it, you deleted it, and it disappeared.

      Have you ever installed one of the following (and these are the first three that spring to mind)?

      Quark Xpress
      Microsoft Office
      MacLink
      Extensions, libraries, fonts, helper programms all over the place

      And don't tell me you forgot the torture that was Extension Manager [foundationstone.com.au] already.

      • Office was pretty smart in Mac Classic. Instead of running as an installer, it would just copy what it needed the first time it ran. Your other examples are valid, though-- there were apps in Mac Classic that requires installers, just not a lot. Same as... *gasp* OS X. So no real change there.

    • Re: (Score:2, Informative)

      by SilverAlicorn ( 986453 )
      Uhh... have you even used Mac OS X? The vast majority of applications are distributed as "bundles," which are basically special directories that contain everything the program needs to run. You can put the bundle whereever you like, and execute it from there, though the OS provides an "Applications" folder to keep everything neat.

      Frameworks, like Quicktime or SDL, work in a similar way, though they get dropped in the "Library/Frameworks" folder.

      The only things that use the Installer are things that need to
    • No, that's not really true. Many apps - and 99% of small apps - install with a drag'n'drop to wherever you want to put it. Some insist on Applications because they've been 'hard-coded' to look for resources there. Most don't however. Only installs that need changes to the system library (added sounds, frameworks, app support, etc) need to go for the full install and security routine.

      If developers used packages more things would be better though I must say.

    • Re: (Score:2)

      by drsmithy ( 35869 )
      But now, Apple has "installation", where install programs put stuff all over the place, and maybe change the state of the system. Just like Windows. Big step backwards.

      It was an inescapable side effect of moving to an OS that actually had the concepts of "security" and "permissions".

  • Not a real concern (Score:3, Informative)

    by John Nowak ( 872479 ) on Saturday September 16, 2006 @02:25PM (#16121215)
    On almost any system today, including Linux, OpenBSD, OS X, etc, software has far too much power. Even if I'm not logged in as an admin user, I could download an application, run it, have it trash my user folder, add some things to my .profile, etc. The truth is that the current 'security' on just about every system out there is a joke if you consider intentionally running a (secretly) malicious application a security problem. I absolutely do, but in the grand scheme of things, if Installer asks for a password or not on OS X to do things as root is not much of a concern compared to the gaping holes already there. Should it be fixed? Yes. Is it a major problem? No.
    • Also, I should mention that OS X which do not require special privileges are installed by dragging them to /Applications (or just running them from where they are -- location rarely matters). The whole point of installer is to let people easily install things that need special privileges.

    • Once you're penetrated... (Score:4, Insightful)

      by argent ( 18001 ) <peter@NOsPAm.slashdot.2006.taronga.com> on Saturday September 16, 2006 @03:28PM (#16121434) Homepage Journal
      There's a great security T-shirt out there that carries the slogan "Once you're penetrated, you're ****ed" (except with the canonical 4LW instead of ****).

      Once an attacker has gained the ability to run unrestricted code on your computer, they can cause you grief even if they have no ability to install applications, install kernel components, run as root or Administrator, or even access the network. Being able to prevent applications from gaining extra privileges is good, at least it makes the cleanup easier, and possibly limits exposure to one account (though anyone who had an account on a shared timesharing system in college knows that's not guaranteed). But for most people, that account has everything they care about on the computer anyway, so once they're penetrated they're ****ed.

      Apple needs to make the following changes to reduce the probability of penetration here.

      1. Don't treat files (like, say, installers) as "safe". Treat applications that operate on files as "safe" or "unsafe", with "safe" limited to applications that are designed to deal with untrusted files.

      2. INSTALLERS AREN'T DESIGNED TO DEAL WITH UNTRUSTED FILES. Don't run an installer automatically.

      3. The user is allowed to shoot himself in the foot, but he has to actually pick up the gun and aim it aware that it might go off. It doesn't go in the bathroom cabinet with the hair dryer.

      Don't mix untrusted and trusted files by default... downloads go in a "Downloads" folder, not on the desktop. Don't automatically install downloaded files, let the user request that. Don't run helper applications that are selected for the Finder or Windows Explorer, keep a separate list of helpers for web browsers and mail software...

      PS: Mozilla folks: the same issue applies to XPI. You've got a big red tag on XPI installer saying 'THIS IS A GUN', but you're still leaving it in the bathroom cabinet next to the hair dryer. Cut that out.

    • Re: (Score:2)

      by SnowZero ( 92219 )
      I could download an application, run it, have it trash my user folder, add some things to my .profile, etc. The truth is that the current 'security' on just about every system out there is a joke if you consider intentionally running a (secretly) malicious application a security problem.

      Well, there's at least one project [nsa.gov] to do this kind of thing, which got taken up [fedoraproject.org] by a popular distribution. The fancy security certified OSes have been doing MAC for a long time. Now it's more a case of getting them distrub

  • Three lines of AppleScript (Score:5, Informative)

    by 93 Escort Wagon ( 326346 ) on Saturday September 16, 2006 @02:35PM (#16121256)
    tell application "Terminal"
        do script "exec bash -c \"touch /Applications/Gotcha\""
    end tell
    If you are in the admin group, you can write into any number of important directories without additional authentication. "Applications" is not the most important one; I used it here because it's visible and obvious. However it's the less-than-obvious ones you need to be concerned about.
  • Next scare: you can actually install stuff programs on Linux, Windows and AIX and those programs could do nasty things... euhm, yeah, that's why you don't just install everything.

  • Seems nobody really got it. (Score:4, Insightful)

    by l0ne ( 915881 ) <millenomi.gmail@com> on Saturday September 16, 2006 @03:47PM (#16121510)
    Admin user in OS X are regular users on the admin group. The default setup creates an admin user. Installer.app allows PKGs run by admin TO RUN AS ROOT AND WRITE ON ROOT:WHEEL OWNED FILES WITHOUT A PASSWORD PROMPT. It's more-or-less OK for admins to write to /Applications. It's not to change /etc/sudoers or similar nefarious things without a prompt.
    • It's more-or-less OK for admins to write to /Applications
      No it's not. Things like this is why you macophiles don't get security. Making system wide changes should not be allowed by default. For example what if I replace Terminal.app with a special Terminal that does keylogging.
  • In TFA, the writer says:

    There exists a pretty significant interface problem with the Apple Installer program such that any package requesting admin access via the AdminAuthorization key, when run in an admin user account, is given full root-level access without providing the user with a password prompt during the install. This is even explained in Apple's Installer documentation as proper behavior.

    Yet on the table here [apple.com], linked to from TFA, the documentation quite clearly states that if a user is already a

  • Whew! (Score:4, Funny)

    by cciRRus ( 889392 ) on Saturday September 16, 2006 @09:53PM (#16122785)
    Good thing I'm using Windows.

  • root (Score:2)

    by Tom ( 822 )
    Application with root access can do evil things. News at 11.

    But yes, as someone else posted:: Windos-like installers are the problem. Most OSX software is still installed by dropping it into Programs and you're done, and I very much like it that way (among other things, it makes it trivial to uninstall software, which is often a nightmare on windos because a good portion of the uninstallers don't clean up properly).
  • I think installing software packages is difficult to get right by its very nature. You usually want software you install to be available to all users. A lot of software also modifies the way OS components work, e.g. which application the file manager will use to open certain types of file, or programs that are run when the system boots. On top of that, some packages provide or depend on libraries that should be available to more than just that software.

    If any of the above are true of the package you're inst
  • (I posted this in another thread a while back)

    Why did they use the "all or nothing" approach of requiring the admin password to install some things? Why not introduce a new model where everything in the filesystem is an object of one of the following types:

    - operating system
    - hardware
    - hardware configuration
    - program
    - program configuration
    - interface configuration
    - data

    Have the option of using different passwords for access to operating system, hardware, and program objects. When you run a program installer

Slashdot Top Deals

God made the integers; all else is the work of Man. -- Kronecker

Close