Make sure that this accessibility bypass is safe here -- BindingFlags.NonPublic - sonarqube

VirtualizingStackPanel vsp =
(VirtualizingStackPanel)typeof(ItemsControl).InvokeMember("_itemsHost",
System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.GetField | System.Reflection.BindingFlags.NonPublic, null,
listBox, null);
I am getting the SonarQube Error
Make sure that this accessibility bypass is safe here -- BindingFlags.NonPublic
How can I resolve this?

This rule discourages using Reflection to access non-public fields.
If you must, use #pragma warning disable S3011 in your code.

Related

Golang Google Admin SDK API Client not setting boolean properties correctly

I am using golang package google.golang.org/api/admin/directory/v1 v0.28.0 to build an administrator CLI for Google G Suite.
The User type (and other types as well) has boolean properties with omitempty json tags. I can set these properties to a value of true, but when I try to set them to false, nothing happens. I believe that this is because the omitempty option means that the value false is ignored when passed.
After a bit of web research, it seems that the answer might be to use pointers and change the type of the boolean properties from bool to *bool. Then set the value by using a bool pointer like this:
user := new(*admin.User)
f := new(bool)
*f = false
user.Suspended = f
I'm not sure why this might work, but it was suggested and confirmed as working in respect of another API.
These API client libraries are auto-generated and I'm not sure how I can test my theory. If anyone has come across this issue in the past, is there a remedy or workaround for it? Could anyone suggest how I can generate my own version of the golang client?

How do I disable ngAria in ngMaterial?

ngAria (an accessibility module) is adding an unnecessary bower import to my Angular Material project - and now it is throwing warnings:
Attribute " aria-label ", required for accessibility, is missing on node
I only added ngAria because it appeared necessary for ngMaterial. My app does not need screen-reader accessibility.
Anyways, how can I remove ngAria from ngMaterial? or at least disable all warnings.
EDIT: It seems the only easy way to disable ngAria's warnings is console.warn = function() {}; which will just turn off your browser's warnings (I do not recommend doing this, since it may hide warnings unrelated to aria)
Disabling messages globally is possible as of 1.1.0:
app.config(function($mdAriaProvider) {
// Globally disables all ARIA warnings.
$mdAriaProvider.disableWarnings();
});
(But do note the discussion in other answers about aria labels being important for accessibility!)
ngAria, to my knowledge, cannot be disabled and should not be disabled it is core part of angular-material.
To disable warnings you can add aria-label="..." to the specific following items
input
md-button
md-dialog
md-icon
md-checkbox
md-radio-button
md-slider
md-switch
I think, I have covered all of them, but there might be other so watch-out!
I think Salal Aslam's answer is better, but if you want to disable the Aria warnings temporarily you could just do a tweak on the console.warn override you suggested in the original question. Something like this perhaps:
console.realWarn = console.warn;
console.warn = function (message) {
if (message.indexOf("ARIA") == -1) {
console.realWarn.apply(console, arguments);
}
};
Edit: for complex situations, more elaborate solutions may be required. Check out Shaun Scovil's Angular Quiet Console
Just add another tag aria-label="WriteHereAnyLabelYouLike" on md-checkbox and it will resolve the issue.
<md-checkbox type="checkbox" ng-model="account.accountant" class="md-primary" layout-align="end" ng-true-value="1" ng-false-value="0" aria-label="ShowHideAccountant" ></md-checkbox>
aria-label="WriteHereAnyLabelYouLike"
If you really want to disable it, you can by simply overwriting or as angular calls it decorating the original mdAria service that's located inside the angular-material library.
angular.module('appname').decorator('$mdAria', function mdAriaDecorator($delegate) {
$delegate.expect = angular.noop;
$delegate.expectAsync = angular.noop;
$delegate.expectWithText = angular.noop;
return $delegate;
});
This is working in angular-material v1.0.6 but you may have to check that all methods have been cleared.
Basically all the above does is replace the public methods exposed to the $mdAria service and it will replace those methods with a noop (no operation).

IPropertyStory doing SetValue without Commit

I'm following this blog to write the same code to change the System.AppUserModel.ID of a window: The Old New Thing :: How do I prevent users from pinning my program to the taskbar?
He is doing:
hr = pps->SetValue(pkey, var);
PropVariantClear(&var);
He does not do a pps->Commit(), I'm getting confused because I have written the code, I do SetValue and I do Commit but my changes won't take.
How come he doesn't do Commit? Is he mistaken? Or is his a special case where you don't need Commit?
Thanks
The issue was, the var was set to a propvariant which was not properly initailized. My InitFromString function was messing up it would forget to set the var.vt. I dont know why a succesful hr was being returned though.

SecTrustedApplicationCreateFromPath being too smart?

I've got an application that also configures and runs a daemon. I am trying to give both the daemon and the application access permissions to the keychain item. The basic code:
SecKeychainItemRef item;
// create a generic password item
SecTrustedApplicationRef appRef[2];
SecAccessRef ref;
SecTrustedApplicationCreateFromPath( NULL, &appRef[0] );
SecTrustedApplicationCreateFromPath( DAEMON_PATH, &appRef[1] );
CFArrayRef trustList = CFArrayCreate( NULL, ( void *)appRef, sizeof(appRef)/sizeof(*appRef), NULL );
SecAccessCreate( descriptor, trustList, &ref );
SecKeychainItemSetAccess( item, ref );
The keychain entry is created, however the only application listed in the Keychain Access tool as always having access is the main application. Let's call it FOO.app. DAEMON_PATH points to the absolute path of the daemon which is in the application bundle -- call it FOO.daemon.
If I manually go within Keychain Access and select the daemon, it does get added to the list.
Any idea on how to get SecTrustedApplicationCreateFromPath to honor the full/absolute path?
If you need an answer today...
I tried to replace access object for existing keychain item with no success, too. So, I decided to modify existing access object rather than replace it, and this approach works well.
The following pseudocode demonstrates the idea. Declarations, CFRelease()s and error checking are stripped for clarity sake.
SecKeychainItemCopyAccess(item, &accessObj);
SecAccessCopySelectedACLList(accessObj, CSSM_ACL_AUTHORIZATION_DECRYPT, &aclList);
assert(CFArrayGetCount(aclList) == 1);
acl = (SecACLRef)CFArrayGetValueAtIndex(aclList, 0);
SecACLCopySimpleContents(acl, &appList, &desc, &prompt_selector);
SecTrustedApplicationCreateFromPath(MY_APP_PATH, &app);
newAppList = CFArrayCreate(NULL, (const void**)&app, 1, NULL);
SecACLSetSimpleContents(acl, newAppList, desc, &psel);
SecKeychainItemSetAccess(item, accessObj);
I used SecAccessCopySelectedACLList to search for an ACL object with an appropriate authorization tag. You may require some other way for ACL filtering.
The straightforward access object creation must be more tricky, you are to create the same ACL structure as Keychain Access app does, rather than use default SecAccessCreate()'s ACLs. I couldn't cope with that way.

Obtaining admin privileges to delete files using rm from a Cocoa app

I am making a small app that deletes log files. I am using an NSTask instance which runs rm and srm (secure rm) to delete files.
I want to be able to delete files in:
/Library/Logs
~/Library/Logs
The issue is that the user account does not have permissions to access some files in the system library folder, such as the Adobe logs subfolder and others. For example, only the "system" user (group?) has r/w permissions for the Adobe logs folder and its contents, and the current user doesn't even have an entry in the permissions shown in the Get Info window for the folder.
What I want to be able to do exactly:
Obtain admin privileges.
Store the password in the Keychain so the app doesn't have to nag the user each time (Is the storage of the password a bad idea? Is it possible?)
Delete a file whatever the file permissions may be.
I am using NSTask because it offers notifications for task completion, getting text output from the task itself, etc. Would I need to use something else? If so, how could I replicate NSTask's completion notifications and output file handle while running rm and srm with admin privileges?
I am looking for the most secure way to handle the situation. i.e. I don't want my application to become a doorway for privilege escalation attacks.
I looked at the Authorization Services Programming Guide but I am not sure which case fits. At first I thought that AuthorizationExecuteWithPrivileges would be a good idea but after reading more on the subject it looks like this method is not recommended for security reasons.
A detailed answer would be very welcome. I'm sure some of you already had to do something similar and have some code and knowledge to share.
Thanks in advance!
Update:
I am now able to make the authentication dialog pop up and obtain privileges, like so:
OSStatus status;
AuthorizationRef authRef;
status = AuthorizationCreate(NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authRef);
AuthorizationRights authRights;
AuthorizationItem authItems[1];
authItems[0].name = kAuthorizationRightExecute;
authRights.count = sizeof(authItems) / sizeof(authItems[0]);
authRights.items = authItems;
AuthorizationFlags authFlags = kAuthorizationFlagDefaults | kAuthorizationFlagExtendRights | kAuthorizationFlagInteractionAllowed;
status = AuthorizationCopyRights(authRef, &authRights, kAuthorizationEmptyEnvironment, authFlags, NULL);
From the looks of it, it seems that the "Factored Application" method looks the most appropriate. The thing is that, to me, rm already seems like an external helper tool. I'm not sure I get the setuid alternative suggested in the documentation. Could I set the setuid bit on rm and run it using the NSTask method I already implemented? This would mean that I wouldn't need to create my own helper tool. Could somebody elaborate on this subject?
I also looked at the BetterAuthorizationSample which is suggested as a more secure and recent alternative to the setuid bit method, but found it awfully complex for such as simple behavior. Any hints?
Thanks in advance for any help!
Perhaps a tad late, but this might be useful for future reference for other people. Most of the code is from this person.
Basically, it has a lot to do with Authorization on the Mac. You can read more about that here and here.
The code, which uses the rm tool:
+ (BOOL)removeFileWithElevatedPrivilegesFromLocation:(NSString *)location
{
// Create authorization reference
OSStatus status;
AuthorizationRef authorizationRef;
// AuthorizationCreate and pass NULL as the initial
// AuthorizationRights set so that the AuthorizationRef gets created
// successfully, and then later call AuthorizationCopyRights to
// determine or extend the allowable rights.
// http://developer.apple.com/qa/qa2001/qa1172.html
status = AuthorizationCreate(NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authorizationRef);
if (status != errAuthorizationSuccess)
{
NSLog(#"Error Creating Initial Authorization: %d", status);
return NO;
}
// kAuthorizationRightExecute == "system.privilege.admin"
AuthorizationItem right = {kAuthorizationRightExecute, 0, NULL, 0};
AuthorizationRights rights = {1, &right};
AuthorizationFlags flags = kAuthorizationFlagDefaults | kAuthorizationFlagInteractionAllowed |
kAuthorizationFlagPreAuthorize | kAuthorizationFlagExtendRights;
// Call AuthorizationCopyRights to determine or extend the allowable rights.
status = AuthorizationCopyRights(authorizationRef, &rights, NULL, flags, NULL);
if (status != errAuthorizationSuccess)
{
NSLog(#"Copy Rights Unsuccessful: %d", status);
return NO;
}
// use rm tool with -rf
char *tool = "/bin/rm";
char *args[] = {"-rf", (char *)[location UTF8String], NULL};
FILE *pipe = NULL;
status = AuthorizationExecuteWithPrivileges(authorizationRef, tool, kAuthorizationFlagDefaults, args, &pipe);
if (status != errAuthorizationSuccess)
{
NSLog(#"Error: %d", status);
return NO;
}
// The only way to guarantee that a credential acquired when you
// request a right is not shared with other authorization instances is
// to destroy the credential. To do so, call the AuthorizationFree
// function with the flag kAuthorizationFlagDestroyRights.
// http://developer.apple.com/documentation/Security/Conceptual/authorization_concepts/02authconcepts/chapter_2_section_7.html
status = AuthorizationFree(authorizationRef, kAuthorizationFlagDestroyRights);
return YES;
}
I had this headache a few months ago. I was trying to get a shell script running with admin privileges that shutdown my computer at a certain time. I feel your pain.
I used the BetterAuthorizationSample which was a total nightmare to wade through. But I took the most pragmatic route - I didn't bother trying to understand everything that was going on, I just grabbed the guts of the code.
It didn't take me that long to get it doing what I wanted. I can't remember exactly what I altered, but you're welcome to check out my code:
http://github.com/johngallagher/TurnItOff
I hope this helps on your quest for a secure application!

Resources