Custom AD group for UnSafePath

[dp001]

I'm playing around with AppLocker for a while now.
AaronLocker makes my life easy.
Normally, EXEs and DLLs in UnSafePath are restricted to a specific AD Group. As number of generate rules can be massive (for example Oracle installed in C:\Oracle), and manually reviewing all related rules very boring... if there is an option to specify a custom AD group SID for them wuold be great.
Something like:
@{
label = "Oracle";
paths = "C:\Oracle";
customUserorGroupSid = "S-1-5-21-4163178468-2177354522-4168272174-26602"
}

Other option is using Static rules, but is painfull to keep updated...

Thanks,
David

[AaronMargosis]

I'm not sure what you're trying to do. Does the KnownAdmins.ps1 customization option not address this?

[AaronMargosis]

OK, I think I understand now. You want to allow a specific user/group to be able to execute whitelisted files in an unsafe directory, but not allow any other non-admins to do so. Is that correct?
First: doesn't Oracle lock down C:\Oracle during install so that it's not non-admin-writable? (It's catastrophically and inexcusably bad if they don't.) If it's not non-admin-writable, then you could just add C:\Oracle to GetSafePaths... which is a lot easier to work with.
Second: "AaronLocker" as a whole distinguishes only between admins and non-admins. If it's going to start being more granular, it needs to be across the board and not just in user-writable directories. I'd prefer not to add that complicating factor at this time.
If you want to allow only certain users to execute in C:\Oracle and it's actually not user-writable, create a rule fragment XML, change the grantee to who you want, and put it in the MergeRules-Static directory.

[dp001]

Unfortunately DB Admins very frequently made Oracle installation directory writable to all users
Some components need modify rights to work correctly

You’re right on what I’m trying achieving: giving access non-admin users access to Oracle (or other apps installed in non standard paths)
Programs installed in common paths (Program Files) are already allowed to everyone

Giving custom execution permission inside those folders is complicated and not sure it is commonly needed.
License enforcement would be the case, but static rules works better

Same for custom folders, but I’m trying automate this instead creating static files

Thanks :)

[AaronMargosis]

So, Oracle locks it down and then DB admins open it back up again? I think the admins of these systems need to decide whether security matters and how to implement it. Re the components with modify rights - I assume those are only data files. Are they in separate subdirectories? If so, open the permissions on those, not on the entire C:\Oracle directory. Does that work?

[dp001]

As far as I know, Oracle client installs in C:\Oracle\client
Normally, users need modify rights folder level

clint folder contains exe and dlls

[AaronMargosis]

OK. I downloaded Oracle client software for Windows x64 (18c / 18.3) from here:
https://www.oracle.com/technetwork/database/enterprise-edition/downloads/oracle18c-windows-180000-5066774.html
I installed it into a VM. It looks like 1) they don't lock down the installation directory, meaning that Authenticated Users gets "Modify" (just shy of Full Control); and 2) none of their files are digitally signed - the only digitally signed files are redistributable Microsoft files.
Did I miss something, or is this "normal" for an Oracle install?
(I have some fierce and strong opinions about this but will hold back for now.)
If you can lock the directory down you can add it to safe-paths. If not then you have to create an entry in UnsafePaths... but maintaining it as it gets updated will be a pain.
(Note that I'm still holding back on telling you what I really think of Oracle's install.)

[michalzobec]

Normally, users need modify rights folder level

Oracle DB Client not needs another rights then Read and Execute for normal users. I have experience with Oracle DB Client 12.2.0 in environment with 800 users and real cca 400-500 users.

[AaronMargosis]

So if Oracle's installer doesn't set the permissions correctly, you must do it as a post-installation step?
(Why doesn't Oracle set correct permissions on those directories? Or install to Program Files where those files belong?)

[michalzobec]

So if Oracle's installer doesn't set the permissions correctly, you must do it as a post-installation step?

right.

(Why doesn't Oracle set correct permissions on those directories? Or install to Program Files where those files belong?)

I dont know, typically use in corporate environment is about make own package. installation path is historical, and maybe is for compatibility with old solution (some starting from 1995 in Pascal and with BDE). I have experience with one company with cca 15+ applications using Oracle Client.

Oracle client had hybrid installation partly in CMD script with support binary files and partly in Java. First phase is due to compatibility with other platforms (MacOS, *nix).

But finally, setting of permissions is task for admin creating deployment task/package. :)

[AaronMargosis]

But finally, setting of permissions is task for admin creating deployment task/package. :)

No. No, it's not. This is a long-standing bug in Oracle's installer.

[michalzobec]

But finally, setting of permissions is task for admin creating deployment task/package. :)

No. No, it's not. This is a long-standing bug in Oracle's installer.

yes, from application point of view, yes. but final configuration of anything in SW deploy package is responsibility for package developer (of target customer).