I have written an Android application that does not require any permission. The fact that it does not require any permission is a proof to the user that it will not leak any sensitive information (typically through internet access).
I intend to run this application through ARC in the chrome browser on Windows/Linux.
Does ARC enforce application permissions? I have read that earlier version of ARC did not enforce anything here:
https://sslab.gtisc.gatech.edu/2014/arc-security.html
Thx for any information.
Not really. Android permission is translated to Chrome Apps permission, because ARC is based on Chrome Apps. But it's not a one-to-one mapping.
Even though you app has no permission, ARC Welder may add default permissions which are implicit on Android. If you want to promise user for using no permission, you can modify the manifest.json in the zip file before uploading the the store.
Related
I'm trying to use CreateAppContainerProfile to run a .NET 6 application.
Based on the documentation that api is used to set up the same kind of sandbox used by UWP applications.
Now this works correctly if the application is installed below c:\program files but if it's installed elsewhere the process fails with "Failed to resolve full path of the current executable [path to the executable]" (code 0x80008085)
If the user account has the WRITE_DAC access right to the application folder I can allow the sandbox read/list_directory access and it works again, but if the user account itself only haves read/list/execute rights there I can't do that.
The documentation for UWP sandboxes say that they implicitly give the sandbox read access to the application directory (which makes sense) and considering the application works in c:\program files without granting any permissions, that seems to somewhat also apply here but I don't understand why it doesn't work the same elsewhere.
Is there some security settings on the folders outside the user rights that would be relevant here?
There is so little documentation on this functionality I'm not entirely sure where else to look for information.
Answering my own question here:
I did really overthink this by assuming that the app container was supposed to magically give read/execute permission to the application directory.
In reality, c:\program files simply has an ACL for the special user "ALL RESTRICTED APPLICATION PACKAGES" that grants all app containers read/execute access to the entire directory tree.
Unfortunately this means there isn't really a nice solution for what I'm looking for apparently. At some point my main process has to be elevated to change ACLs to the application directory so that the app container can read it, there is no way afaict to just "inherit" rights the host process has to the containerized one.
"Capabilities" can be used when creating the appcontainer to allow access to certain predefined functionality (libraries, devices, ...) or you can basically set up custom capabilities, like a set of directories a container should be able to access but that then again requires the right to change ACLs on those directories when setting up the capability.
According to the Mac App Store Review Guidelines:
2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind:
(i) They must be appropriately sandboxed, and follow macOS File System Documentation. They should also only use the appropriate macOS APIs for modifying user data stored by other Apps (e.g. bookmarks, Address Book, or Calendar entries).
...
(iv) They may not download or install standalone apps, kexts, additional code, or resources to add functionality or significantly change the app from what we see during the review process.
(v) They may not request escalation to root privileges or use setuid attributes.
Sandboxing already precludes the use of APIs such as AuthorizationCreate(), and anyway, item (v) is pretty clear.
Certainly an app like, say, Parallels (MAS link) can't be coded without ever resorting to privilege escalation. Indeed, the regular (non-MAS) Parallels app installs at least 3 kexts, one of them being the hypervisor, without which I believe Parallels would be absolutely useless. So they are clearly violating these rules.
If a developer wished to write an app that, like Parallels, needs privilege escalation and is completely useless without it, how would the developer go about bypassing these restrictions? Or is it just a question of being big enough that Apple will turn a blind eye to this during the review process? Can you request an exception to Apple?
No comment on the App Store policy issue (unfortunately), but I can answer your question about Parallels. The version of Parallels on the Mac App Store does not use a kext, nor does it need to. The Hypervisor framework makes it possible to write a Parallels-like application without needing root privileges, or writing and distributing a custom kext (which requires separate approval by Apple). The Hypervisor framework is also usable from sandboxed apps. I believe this framework was created specifically to workaround this problem. Hope this helps!
If I want to give an appx app package to someone to sideload on a windows 10 pc with a developer account, is there any way to prevent the appx package from being distributed online?
When it is in the Windows store, the store handles payment and basic licensing. There is no strategy whereby I could revoke a side-loaded app???
Thanks...
The appx package doesn't provide anything for you to verify the usage of it. Anyone can install with your package.
But you can create your own account system by setup a server and ask your user to login to use your features. If they are not licensed user when you verify their account, you can disable the navigating behavior from your app to prevent they use your functions. This means although they can install your app, they may not able to use the functions you provided behind your verification. Does this make sense to you?
If you intend to deploy the app in the store you should submit an .appxupload. The .appx is only used to sideload the app on a device.
Of course anyone that has access to the .appx can do whatever they want with it - like for example side-loading it - just like they can do whatever they want with an .exe. There is no functionality within the .appx deployment technology that allows you to "revoke a side-loaded app" from an unknown computer that you don't have access to if that's what you are asking.
If you want to restrict the access to your app, or rather the app content, you should implement some kind of authentication and/or authorization within the app itself. You could for example connect to a remote service that grants access to user's at startup.
In a Cocoa MacOS Application that delivers a Finder Sync extension, can I create a non sandboxed XPC Service, communicate and use it ? If not, what are the options in both the Mac App Store and the independent distribution Scenarios ? So far, I have attempted to add a Finder Sync target to the Even Better Authorization Sample from Apple, but the XPC service only works from the sandboxed app, not the Finder Sync Extension, even if I use the method they ship that does not need admin privileges. Therefore, I have given up for the moment to ask if I am missing something important. I have the same behaviour regardless of the signature settings, either for Mac App Store or Developer ID. I am getting error 4099 - The connection was invalidated. I have found this article that is on topic, but could not succeed to make the author's solution work.
After developing my first Mac app I've decided to submit it to the Mac App Store but it got rejected. Basically my app uses NSOpenPanel for reading Xcode project file and NSSavePanel for saving file after it finishes it's work.
Reviewer pointed out that app is violating 2.30 rule - Apps that do not comply with the Mac OS X File System documentation will be rejected, but I'm unclear why.
When you look at app's workspace you can see it uses CocoaPods for handling dependencies which shouldn't be a problem. Next it has JBLocalizer.framework which is being linked as an embedded library to JBLocalizerApp. JBLocalizerApp is final target sent to the review.
Here is what reviewer pointed out as a problem:
2.30
The application accesses the following location(s):
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBString.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBPostProcessStringsOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBLoadStringsInFileOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBLoadSourceFilesOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBLoadRootFilesOperation.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBFileController.gcda'
'/Users/josipbernat/Library/Developer/Xcode/DerivedData/Build/Intermediates/ArchiveIntermediates/JBLocalizerApp/IntermediateBuildFilesPath/JBLocalizer.build/Release/JBLocalizer.build/Objects-normal/x86_64/JBFile.gcda'
The majority of developers encountering this issue are opening files
in Read/Write mode instead of Read-Only mode, in which case it should
be changed to Read-Only.
Other common reasons for this issue include:
creating or writing files in the above location(s), which are not valid locations for files to be written as stated in documentation
writing to the above location(s) without using a valid app-id as a container for the written files
Please review the "File-System Usage Requirements for the App Store"
of Submitting to the Mac App Store for the locations apps are allowed
to write and for further guidance.
I'm really not sure how can my app violate access to the library which is being linked to. Any suggestions?
You've got Code Coverage turned on in your project settings.
See QA1514 on how it's turned on, which should help you turn it off.