Is checkCallingPermission() without PID check insecure
Following is the code for checkCallingPermission() in Android O:
public static int checkCallingPermission(@NonNull Context context,
@NonNull String permission, String packageName) {
if (Binder.getCallingPid() == Process.myPid()) {
return PackageManager.PERMISSION_DENIED;
}
return checkPermission(context, permission, Binder.getCallingPid(),
Binder.getCallingUid(), packageName);
}
There is PID check which denies permission if calling PID matches local PID.
I am trying to understand why this was added. Does this check avoid a security issue?
Background:
I have a AAR library that some customers will (1) use in their app by including directly, and others will (2) use wrapped in a service through binder. In both cases, the Customer app must have a specific system permission for successfully calling my API, and other third party apps that don't have that permission should be denied access to my API.
I want to write code that would do checkSelfPermission() for case(1) but would do checkCallingPermission() for case (2)
A good way to do that seems to use the following code:
mContext.checkPermission(mPermStr, Binder.getCallingPid(), Binder.getCallingUid()));
This effectively achieves what I want.
I am trying to understand if I introduced any security or permission leakage issues through this.
android permissions asked Nov 23 '18 at 10:54
GPSGPS
793827
add a comment |
Following is the code for checkCallingPermission() in Android O:
public static int checkCallingPermission(@NonNull Context context,
@NonNull String permission, String packageName) {
if (Binder.getCallingPid() == Process.myPid()) {
return PackageManager.PERMISSION_DENIED;
}
return checkPermission(context, permission, Binder.getCallingPid(),
Binder.getCallingUid(), packageName);
}
There is PID check which denies permission if calling PID matches local PID.
I am trying to understand why this was added. Does this check avoid a security issue?
Background:
I have a AAR library that some customers will (1) use in their app by including directly, and others will (2) use wrapped in a service through binder. In both cases, the Customer app must have a specific system permission for successfully calling my API, and other third party apps that don't have that permission should be denied access to my API.
I want to write code that would do checkSelfPermission() for case(1) but would do checkCallingPermission() for case (2)
A good way to do that seems to use the following code:
mContext.checkPermission(mPermStr, Binder.getCallingPid(), Binder.getCallingUid()));
This effectively achieves what I want.
I am trying to understand if I introduced any security or permission leakage issues through this.
android permissions asked Nov 23 '18 at 10:54
GPSGPS
793827
I am guessing that only reason check is added, is that someone may call this method assuming it checks only for a IPC caller's permissions, and not local permission, but inadvertently ends up granting own permission. I don't see any other level of security issue with this method.
– GPS
Nov 27 '18 at 6:59
add a comment |
Following is the code for checkCallingPermission() in Android O:
public static int checkCallingPermission(@NonNull Context context,
@NonNull String permission, String packageName) {
if (Binder.getCallingPid() == Process.myPid()) {
return PackageManager.PERMISSION_DENIED;
}
return checkPermission(context, permission, Binder.getCallingPid(),
Binder.getCallingUid(), packageName);
}
There is PID check which denies permission if calling PID matches local PID.
I am trying to understand why this was added. Does this check avoid a security issue?
Background:
I have a AAR library that some customers will (1) use in their app by including directly, and others will (2) use wrapped in a service through binder. In both cases, the Customer app must have a specific system permission for successfully calling my API, and other third party apps that don't have that permission should be denied access to my API.
I want to write code that would do checkSelfPermission() for case(1) but would do checkCallingPermission() for case (2)
A good way to do that seems to use the following code:
mContext.checkPermission(mPermStr, Binder.getCallingPid(), Binder.getCallingUid()));
This effectively achieves what I want.
I am trying to understand if I introduced any security or permission leakage issues through this.
android permissions asked Nov 23 '18 at 10:54
GPSGPS
793827
Following is the code for checkCallingPermission() in Android O:
public static int checkCallingPermission(@NonNull Context context,
@NonNull String permission, String packageName) {
if (Binder.getCallingPid() == Process.myPid()) {
return PackageManager.PERMISSION_DENIED;
}
return checkPermission(context, permission, Binder.getCallingPid(),
Binder.getCallingUid(), packageName);
}
There is PID check which denies permission if calling PID matches local PID.
I am trying to understand why this was added. Does this check avoid a security issue?
Background:
I have a AAR library that some customers will (1) use in their app by including directly, and others will (2) use wrapped in a service through binder. In both cases, the Customer app must have a specific system permission for successfully calling my API, and other third party apps that don't have that permission should be denied access to my API.
I want to write code that would do checkSelfPermission() for case(1) but would do checkCallingPermission() for case (2)
A good way to do that seems to use the following code:
mContext.checkPermission(mPermStr, Binder.getCallingPid(), Binder.getCallingUid()));
This effectively achieves what I want.
I am trying to understand if I introduced any security or permission leakage issues through this.
android permissions android permissions asked Nov 23 '18 at 10:54
GPSGPS
793827
asked Nov 23 '18 at 10:54
GPSGPS
793827
asked Nov 23 '18 at 10:54
GPSGPS
793827
asked Nov 23 '18 at 10:54
GPSGPS
793827
asked Nov 23 '18 at 10:54
GPSGPS
793827
793827
I am guessing that only reason check is added, is that someone may call this method assuming it checks only for a IPC caller's permissions, and not local permission, but inadvertently ends up granting own permission. I don't see any other level of security issue with this method.
– GPS
Nov 27 '18 at 6:59
add a comment |
I am guessing that only reason check is added, is that someone may call this method assuming it checks only for a IPC caller's permissions, and not local permission, but inadvertently ends up granting own permission. I don't see any other level of security issue with this method.
– GPS
Nov 27 '18 at 6:59
I am guessing that only reason check is added, is that someone may call this method assuming it checks only for a IPC caller's permissions, and not local permission, but inadvertently ends up granting own permission. I don't see any other level of security issue with this method.
– GPS
Nov 27 '18 at 6:59
I am guessing that only reason check is added, is that someone may call this method assuming it checks only for a IPC caller's permissions, and not local permission, but inadvertently ends up granting own permission. I don't see any other level of security issue with this method.
– GPS
Nov 27 '18 at 6:59
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53445332%2fis-checkcallingpermission-without-pid-check-insecure%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53445332%2fis-checkcallingpermission-without-pid-check-insecure%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I am guessing that only reason check is added, is that someone may call this method assuming it checks only for a IPC caller's permissions, and not local permission, but inadvertently ends up granting own permission. I don't see any other level of security issue with this method.
– GPS
Nov 27 '18 at 6:59