October 2008 - Darwin-dev - lists.apple.com

Re: setuid for priv sockets?
by Kevin Van Vechten 28 Oct '08

28 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Oct 27, 2008, at 8:22 PM, Brian Mastenbrook wrote: - Kevin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Oct 27, 2008, at 8:15 PM, Damien Sorresso wrote: If you use a system-level launchd daemon, however, your execution environment is implicitly trusted, since /sbin/launchd is implicitly trusted. A user cannot affect the environment of your daemon *at all* because the parent process is launchd, not the client process. ... except by communicating with the daemon. How many local root exploits have been due to daemons running on the localhost which accept but do not properly validate input from clients? How many remote exploits? We are still operating in the mindset of launching a piece of code with root privileges that receives tainted data from a user process, and any such program is suspect for the same set of reasons that make writing setuid helper tools difficult - and possibly moreso, because now I have to deal with socket interactions to read and parse the request rather than just reading and validating some pre-tokenized arguments in argv. Sample code or no, there's still significant opportunity for error here. I strongly disagree. A setuid-root executable has a much larger attack surface than a launchd helper. All framework/library interfaces by the setuid-root executable can potentially receive untrusted data via the user environment, mach bootstrap registrations, inherited file descriptors, etc. A privileged launchd helper has none of these attack surfaces, only the communication protocol. It is far more tractable to audit the parsing of the communication protocol than all framework/library interfaces used by the executable. This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid for priv sockets?
by Brian Mastenbrook 28 Oct '08

28 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net On Oct 27, 2008, at 10:37 PM, "Jordan K. Hubbard" <jkh(a)apple.com> wrote: On Oct 27, 2008, at 4:11 PM, Brian Mastenbrook wrote: If it were all particularly easy, we'd have done it already. - Jordan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Jordan, I'm pretty sure I knew I was talking about capabilities, seeing as that's the exact word I used several times in a row :-) Also, I'm well aware that it's not easy, which is why I made reference to spending some of those copious billions in cash. Sometimes you've got to invest to maintain a key advantage over your primary competitor. Right now I am frankly very concerned that Apple is marching down a path that does nothing to address the ease with which something that manages to execute arbitrary code from the browser can become root on an average Mac. Nothing other than dumb luck is keeping drive-by malware off the platform right now. I am not a security professional. I spend very little time thinking about this beyond what is necessary to secure my own applications. Twice this year I have submitted security bugs which I have stumbled across that have allowed easy execution of arbitrary shell scripts from Safari without user interaction. (The fact that I have stumbled across these issues easily probably means there are more issues lurking out there...) All the payload needs to do is to wait for Apple to release a software update and it will have root. Heck, the very update that fixes the vulnerability can be the infection vector. Now make the root portion a DHCP server, and you've got yourself a virus that hops from computer to computer over any network, infecting Safari users as it goes. Just to top off our Halloween scenario, imagine it gets into Apple's network. Now the iPod clones are popping on the grey market a week *before* a new design is announced. I don't think the stockholders would be very happy in that scenario! I would like to think that Apple will invest in the necessary security technologies before this scenario happens, but at the moment I don't see any reason to be hopeful. I do agree that implementing setuid binaries is tricky, and the ordinary (or even extraordinary) developer can't be trusted to do it correctly. The alternative is not to do something worse simply because it's easier. I wish Apple would throw some of its copious billions at actually improving the situation. What's needed is a very fine grained set of capabilities, along with the ability to selectively grant those capabilities to an application at either installation or execution time (with corresponding limitations on the ability to influence the execution environment ala the existing restrictions for setuid binaries). Instead we are marching headlong down a path of desensitizing the users to constant authentication dialogs. This way lies Windows. What you're describing is widely known as "capabilities". A fine grained authorization model certainly beats the one, big "are you root or not?" hammer, to be sure, but it's hardly some panacea. Now you have to figure out how to confer all those little capabilities in their various combinations onto user accounts (since the notion of "are you admin or not?" is only "are you root or not?" under a different label). You need to figure out how to grant a specific capability to a specific (presumably signed) binary since making it setuid anything is also now too coarse grained. You need to figure out how to acquire those individual rights at runtime for a user with the right password / smart card / other authentication device without creating an entirely new profusion of user dialogs since all usage scenarios don't conform to being able to know up- front that you're going to need capability X for binary Y. This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid for priv sockets?
by Jordan K. Hubbard 28 Oct '08

28 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Oct 27, 2008, at 4:11 PM, Brian Mastenbrook wrote: If it were all particularly easy, we'd have done it already. - Jordan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I do agree that implementing setuid binaries is tricky, and the ordinary (or even extraordinary) developer can't be trusted to do it correctly. The alternative is not to do something worse simply because it's easier. I wish Apple would throw some of its copious billions at actually improving the situation. What's needed is a very fine grained set of capabilities, along with the ability to selectively grant those capabilities to an application at either installation or execution time (with corresponding limitations on the ability to influence the execution environment ala the existing restrictions for setuid binaries). Instead we are marching headlong down a path of desensitizing the users to constant authentication dialogs. This way lies Windows. What you're describing is widely known as "capabilities". A fine grained authorization model certainly beats the one, big "are you root or not?" hammer, to be sure, but it's hardly some panacea. Now you have to figure out how to confer all those little capabilities in their various combinations onto user accounts (since the notion of "are you admin or not?" is only "are you root or not?" under a different label). You need to figure out how to grant a specific capability to a specific (presumably signed) binary since making it setuid anything is also now too coarse grained. You need to figure out how to acquire those individual rights at runtime for a user with the right password / smart card / other authentication device without creating an entirely new profusion of user dialogs since all usage scenarios don't conform to being able to know up-front that you're going to need capability X for binary Y. This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid for priv sockets?
by Brian Mastenbrook 28 Oct '08

28 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Damien, On Oct 27, 2008, at 8:15 PM, Damien Sorresso wrote: Yes - I do not think that setuid binaries are great, as I mentioned. -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I think I'm beginning to see that I'm not communicating very clearly. :-) I am viewing the problem as an attacker, and as such I am probably missing distinctions that are important to the users and implementors of these APIs. If SuperFancyEthernetCaptureProgram is requesting my user name and password, who am I to argue with it? Nevermind that TotallyEvilMaware.dylib has injected itself into the process and will be rooting my system at the same time. By contrast, the execution environment of setuid binaries is locked down so that other user programs can't influence it. Even sudo itself is setuid and is this isolated from the effects of PATH, DYLD_INSERT_LIBRARIES, and other magic. The lockdown of setuid binaries is enforced across multiple components. dyld will refuse to honor the DYLD_INSERT_LIBRARIES environment variable for setuid binaries, and the setuid(2) call itself will (I believe) clean out some environment variables. But the parent process can still corrupt the environment of the setuid process. (For example, setuid programs inherit file descriptors in exactly the same fashion as any other program.) But you're conflating the safeness of the execution environment with its trustworthiness. While setuid binaries execute in a slightly safer environment because of little tricks here and there, their environment is far less trustworthy because *anyone* with executable access to the binary can run it with elevated privileges. The onus of sanitizing the environment still rests with the author. If you use a system-level launchd daemon, however, your execution environment is implicitly trusted, since /sbin/launchd is implicitly trusted. A user cannot affect the environment of your daemon *at all* because the parent process is launchd, not the client process. ... except by communicating with the daemon. How many local root exploits have been due to daemons running on the localhost which accept but do not properly validate input from clients? How many remote exploits? We are still operating in the mindset of launching a piece of code with root privileges that receives tainted data from a user process, and any such program is suspect for the same set of reasons that make writing setuid helper tools difficult - and possibly moreso, because now I have to deal with socket interactions to read and parse the request rather than just reading and validating some pre- tokenized arguments in argv. Sample code or no, there's still significant opportunity for error here. I really think you should read the AuthorizationServices documentation. Don't take the existence of AuthorizationExecuteWithPrivileges() to mean that it's the standard way to do privilege escalation on Mac OS X. And please don't labor under the impression that setuid binaries are the safest way to elevate privileges on Mac OS X. They're not. See BetterAuthorizationSample and/or the WWDC security talk (if you have access). I have read the documentation. I don't have access to the WWDC security talk. Even if APIs other than AuthorizationExecuteWithPrivileges are used, any method of performing privileged operations that results in a password dialog box is suspect. There are multiple problems with this password dialog box. There is little-to-no useful information about which right exactly is being requested. If multiple rights are requested, only the first is displayed. Nobody bothers to check what's behind the disclosure triangle anyway. The dialog can be spoofed. If the user whose credentials are entered has administrative access, anything running as my user now has root - even if the requested right did not require admin! Attempting to split the logic of the application into a safe portion which only runs in a trusted environment (invoked by launchd) and an unsafe portion which runs as an ordinary user is very difficult in non- trivial cases. Having logic which is very difficult to implement that needs to run as root is the same situation that got us into the setuid mess in the first place. *Any* access by an an unsafe user process to privileged operations is problematic. Allowing an ordinary user process access to snoop Ethernet traffic is the same as allowing anything that happens to be running in my user account access to this right. If that's all I wanted to accomplish, I could just change the permissions on /dev/ bpf*, and then I wouldn't have a helper tool running as root to worry about implementing correctly. AuthorizationExecuteWithPrivileges() is used also very commonly. BetterAuthorizationSample uses it to install its helper tool. Software Update and System Preferences use it. The root of my point is this: if privilege escalation is done with setuid programs, I have to find a setuid program which has been badly written in order to gain root. Why would I bother when I can hijack Software Update, or the LowNumberedPorts part of BetterAuthorizationSample? This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid for priv sockets?
by Jordan K. Hubbard 28 Oct '08

28 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Oct 27, 2008, at 2:49 PM, Stephen Hoffman wrote: - Jordan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Not passing out root or sudo access is a common practice in various production and security-conscious environments. Within those environments (and I deal with folks that are severely allergic to passing out root access), setuid can be an invaluable palliative. I'm quite willing to move to another approach or environment or tool or interface here. But suggesting that they pass out root access as a solution for starting up certain command-line tools is just going to get me a heaping raft of static with these good folks. I think Damien might have been a little too sweeping in his generalizations; I don't think anyone is suggesting that the user should be, or needs to be, involved in all such privilege decisions, it's just one additional approach. For the cases you're talking about, having Launchd start the helper tool and confer privileges to it, rather than making that tool setuid, is the answer. This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid for priv sockets?
by Damien Sorresso 28 Oct '08

28 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com http://developer.apple.com/documentation/Security/Conceptual/authorization_… _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com On Oct 27, 2008, at 2:49 PM, Stephen Hoffman wrote: Damien Sorresso writes: We're strongly (and I do mean strongly) trying to move people off of setuid binaries. If it's a command line application, you can just require that the user run it as root or with sudo if performing actions that require access to this privileged port. Not passing out root or sudo access is a common practice in various production and security-conscious environments. Within those environments (and I deal with folks that are severely allergic to passing out root access), setuid can be an invaluable palliative. I'm quite willing to move to another approach or environment or tool or interface here. But suggesting that they pass out root access as a solution for starting up certain command-line tools is just going to get me a heaping raft of static with these good folks. Please don't take away setuid without an alternative. And no, sudo isn't a solution. Then I'd suggest having a launchd job running under the system launchd (as root) open the socket and give a file descriptor back to your utility. If you're creating a simple command-line utility that you're distributing in controlled environments, you can simply create an installer that lays down the job's bits. On Oct 27, 2008, at 4:11 PM, Brian Mastenbrook wrote: I'm sorry, but using AuthServices to replace setuid binaries is simply broken from a security perspective. A setuid binary, *if correctly implemented*, does a very specific set of things while it has permissions and then permanently drops those rights. AuthorizationServices is not a replacement for setuid-root binaries. It is a set of APIs that authorize a user for a named right. That is all. What you do with that information is entirely at your discretion. Using AuthServices, any old application can come along and request privileges. Sure, I have to approve that request by entering my name and password, but there's absolutely nothing preventing malware that has access to my user account from smuggling along and gaining root permissions at the same time, and there's nothing to tell me that this is happening. I don't think you understand what AuthorizationServices is. Please read the relevant documentation. If SuperFancyEthernetCaptureProgram is requesting my user name and password, who am I to argue with it? Nevermind that TotallyEvilMaware.dylib has injected itself into the process and will be rooting my system at the same time. By contrast, the execution environment of setuid binaries is locked down so that other user programs can't influence it. Even sudo itself is setuid and is this isolated from the effects of PATH, DYLD_INSERT_LIBRARIES, and other magic. The lockdown of setuid binaries is enforced across multiple components. dyld will refuse to honor the DYLD_INSERT_LIBRARIES environment variable for setuid binaries, and the setuid(2) call itself will (I believe) clean out some environment variables. But the parent process can still corrupt the environment of the setuid process. (For example, setuid programs inherit file descriptors in exactly the same fashion as any other program.) But you're conflating the safeness of the execution environment with its trustworthiness. While setuid binaries execute in a slightly safer environment because of little tricks here and there, their environment is far less trustworthy because *anyone* with executable access to the binary can run it with elevated privileges. The onus of sanitizing the environment still rests with the author. If you use a system-level launchd daemon, however, your execution environment is implicitly trusted, since /sbin/launchd is implicitly trusted. A user cannot affect the environment of your daemon *at all* because the parent process is launchd, not the client process. I do agree that implementing setuid binaries is tricky, and the ordinary (or even extraordinary) developer can't be trusted to do it correctly. The alternative is not to do something worse simply because it's easier. I wish Apple would throw some of its copious billions at actually improving the situation. What's needed is a very fine grained set of capabilities, along with the ability to selectively grant those capabilities to an application at either installation or execution time (with corresponding limitations on the ability to influence the execution environment ala the existing restrictions for setuid binaries). Instead we are marching headlong down a path of desensitizing the users to constant authentication dialogs. This way lies Windows. I've already filed this with Apple and they've decided it's not a security issue. For those with Radar access, see rdar://6074066 . I really think you should read the AuthorizationServices documentation. Don't take the existence of AuthorizationExecuteWithPrivileges() to mean that it's the standard way to do privilege escalation on Mac OS X. And please don't labor under the impression that setuid binaries are the safest way to elevate privileges on Mac OS X. They're not. See BetterAuthorizationSample and/or the WWDC security talk (if you have access). -- Damien Sorresso BSD Engineering Apple Inc. smime.p7s

1 0

Re: setuid for priv sockets?
by Brian Mastenbrook 27 Oct '08

27 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Oct 27, 2008, at 1:19 PM, Damien Sorresso wrote: On Oct 27, 2008, at 5:49 PM, Duane Murphy wrote: --- At Mon, 27 Oct 2008 17:49:35 -0400, Stephen Hoffman wrote: -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… We're strongly (and I do mean strongly) trying to move people off of setuid binaries. If it's a command line application, you can just require that the user run it as root or with sudo if performing actions that require access to this privileged port. In the past BSDLLCTest <http://developer.apple.com/samplecode/BSDLLCTest/ index.html> and MoreAuthSample have been the reference for how to o similar functions. The solution described can use setuid root tools (set afterward). Might be worth a look. I'm sorry, but using AuthServices to replace setuid binaries is simply broken from a security perspective. A setuid binary, *if correctly implemented*, does a very specific set of things while it has permissions and then permanently drops those rights. Using AuthServices, any old application can come along and request privileges. Sure, I have to approve that request by entering my name and password, but there's absolutely nothing preventing malware that has access to my user account from smuggling along and gaining root permissions at the same time, and there's nothing to tell me that this is happening. If SuperFancyEthernetCaptureProgram is requesting my user name and password, who am I to argue with it? Nevermind that TotallyEvilMaware.dylib has injected itself into the process and will be rooting my system at the same time. By contrast, the execution environment of setuid binaries is locked down so that other user programs can't influence it. Even sudo itself is setuid and is this isolated from the effects of PATH, DYLD_INSERT_LIBRARIES, and other magic. I do agree that implementing setuid binaries is tricky, and the ordinary (or even extraordinary) developer can't be trusted to do it correctly. The alternative is not to do something worse simply because it's easier. I wish Apple would throw some of its copious billions at actually improving the situation. What's needed is a very fine grained set of capabilities, along with the ability to selectively grant those capabilities to an application at either installation or execution time (with corresponding limitations on the ability to influence the execution environment ala the existing restrictions for setuid binaries). Instead we are marching headlong down a path of desensitizing the users to constant authentication dialogs. This way lies Windows. I've already filed this with Apple and they've decided it's not a security issue. For those with Radar access, see rdar://6074066 . This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid for priv sockets?
by Duane Murphy 27 Oct '08

27 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --- At Mon, 27 Oct 2008 17:49:35 -0400, Stephen Hoffman wrote: >Damien Sorresso writes: > >> We're strongly (and I do mean strongly) trying to move people off of >> setuid binaries. If it's a command line application, you can just >> require that the user run it as root or with sudo if performing >> actions that require access to this privileged port. > >Not passing out root or sudo access is a common practice in various >production and security-conscious environments. Within those >environments (and I deal with folks that are severely allergic to >passing out root access), setuid can be an invaluable palliative. > >I'm quite willing to move to another approach or environment or tool or >interface here. But suggesting that they pass out root access as a >solution for starting up certain command-line tools is just going to >get me a heaping raft of static with these good folks. > >Please don't take away setuid without an alternative. And no, sudo >isn't a solution. In the past BSDLLCTest <http://developer.apple.com/samplecode/BSDLLCTest/ index.html> and MoreAuthSample have been the reference for how to o similar functions. The solution described can use setuid root tools (set afterward). Might be worth a look. In the past, it has been suggested that if you follow Apple's suggestions they will at least try and help with a new solution if one is required. There are lots (and I mean lots) of us that use solutions similar to MoreAuthSample. ...Duane _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid for priv sockets?
by Finlay Dobbie 27 Oct '08

27 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=V+jFyS2tl7rjdNNe6RKf9HKV5POI/OMlgefpKIqbz+E=; b=JLiemY88jT6+99HnvnFtutV3gQyGDcOJSVx/q1u0oCzFiFTDeFhJwq5xD8ks9vqB1u pW92jSiTlJ9k+UplEjtjcKQO4HFjRjKGFXwyAlKv8u7g5mDzc6BtgG587L/gSX4a8wdi 115lXeMYyhIK6AfjTZb8fyk08XbJBTJDiMQK0= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=ULWlqFfDSvkL0dJpbmjc+Gn5IKg2GIgYn9HYzKK61L9710CZZhPGwmZ/5Jy7DvYSPr 1z8S9W/g9bEQsyPbBjZdTG0JOPY89906z2SobutHtt3/QWvd7VYaNE3/qKZawZlQL6Qu 0r5JrUl26JHk2haupkGHXjY/qvMHYndriI6VM= On Mon, Oct 27, 2008 at 9:49 PM, Stephen Hoffman <Hoff(a)hoffmanlabs.com> wrote: > Please don't take away setuid without an alternative. And no, sudo isn't a > solution. http://developer.apple.com/samplecode/BetterAuthorizationSample/index.html illustrates an approach to this. It's not pretty :) -- Finlay _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid for priv sockets?
by Stephen Hoffman 27 Oct '08

27 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: HoffmanLabs LLC User-agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Damien Sorresso writes: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… We're strongly (and I do mean strongly) trying to move people off of setuid binaries. If it's a command line application, you can just require that the user run it as root or with sudo if performing actions that require access to this privileged port. Not passing out root or sudo access is a common practice in various production and security-conscious environments. Within those environments (and I deal with folks that are severely allergic to passing out root access), setuid can be an invaluable palliative. I'm quite willing to move to another approach or environment or tool or interface here. But suggesting that they pass out root access as a solution for starting up certain command-line tools is just going to get me a heaping raft of static with these good folks. Please don't take away setuid without an alternative. And no, sudo isn't a solution. This email sent to site_archiver(a)lists.apple.com

1 0