I don't find any information about how are the special case NULL DACL and empty DACL treated in Windows.
I understand what they are but don't know how they are treated..
Null DACLs and Empty DACLs
A null DACL grants full access to any user that requests it; normal security checking is not performed with respect to the object. ... An empty DACL grants no access to the object it is assigned to.
Another way to think of it, an empty list is not really special at all but because it is empty it has no ACLs that can grant anything.
On the other hand, a NULL DACL granting access is a design decision made by the Windows developers.
Related
I need to call CreateProcessWithLogonW, for which I need to pass builtin account name (say Administrator). The problem is that builtin account names are localized. For example in French its "Administrateur" and when I pass "Administrator" to the function, it returns ERROR_LOGON_FAILURE.
In order to get a builtin account name, I can pass its SID to LookupAccountBySid. Pretty easy. The problem is that, according to this, the SID I need to pass is following:
S-1-5-21domain-500
How do I get the domain part?
I found this code, but in order to get current user's SID (from where I could get the domain part), it calls chain of functions including OpenProcessToken, GetTokenInformation, HeapAlloc, GetSidIdentifierAuthority, GetSidSubAuthorityCount, GetSidSubAuthority...
This would be rather insane for getting simple domain string. Is there a shorter way to do this?
JSON API REST endpoint with permissions-restricted fields
I am working on a JSON API-compliant REST api. Some endpoints contain fields that should be restricted (read-only or not available) for certain users.
What is the best way to architect the api to allow that certain users have access to certain fields, while others do not? By "best", I mean:
Most compliant with REST standards, ideally JSON API standards
Most clarity in terms of preventing bugs and confusion on behalf of clients consuming the API
I am considering the following options, each with their set of concerns/ questions. I would be more than grateful for any other solutions!
Option 1: Return null on restricted fields for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Lack of distinction between null meaning "null value" and null meaning "You don't have access to this"
In REST/ JSON API architecture, is it okay for an endpoint to return different data per user, based on permissions? I have the impression that this would be contrary to the spirit of resource-based REST architecture, but I could not find anything specific to point to in any doc or standard (e.g. JSON API). Also applies to Option 2.
Is there any paradigm for adding some sort of "You don't have access" flag in the resource's metadata?
Option 2: Exclude restricted fields entirely for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Possibility of "undefined" errors in client, when trying to retrieve field value
Option 3: Move restricted field(s) onto another endpoint, available as an ?include='field_name' relation for those with permission
Example: /api/entity includes attribute field "cost" which is only available to Admin users. Admin users can request cost data via GET /api/entity?include=cost. For all users, "cost" is exposed as a relation in the resource object, with a "type" and "id".
This is the option I am leaning toward. The main con here is endpoint clutter. I have a lot of relations that would need to be made into separate endpoints, simply to support a permissions-quarantined data on an already-existing endpoint.
In the JSON API specs, I am having trouble determining if it's ok for an endpoint to exist as a relation only, e.g. can we have /api/entity/1/cost, but NOT have a top-level api endpoint, /api/cost. My assumption is that if a resource has a "type" (in this case, the relation type being 'cost'), it also has to live on a top-level endpoint.
In this scenario, the client could get a 401: Unauthorized error response if a non-admin user tries to GET /api/entity?include=cost or GET /api/cost/:id
Note: I have already built a separate permissions schema so that the client can determine which CRUD privileges the user has, per top-level endpoint, before making any requests. Permission sets are indexed by resource type.
Any help on the matter would be very much appreciated! And if anything needs to be clarified, feel free to ask.
I would definitely not use undefined or null to indicate fields that the user is not allowed to see. To me, that feels like a lie and represents that the data is really not there. They would have to really know your API in order to get a grasp of what is really going on.
I would recommend something more like your 3rd option, except I would make it a different endpoint altogether. So in your example, the endpoints would be:
/api/entity/1/cost
and for admins
/api/admin/entity/1/cost
or something like that.
This way your server code for the admin endpoint could just be focused on authenticating this admin user and getting them back all the fields that they have visibility on. If a non admin user tries to hit that route, reject them with an unauthorized status code.
I'm not saying that you should not implement the GET param to be able to specify fields as well. You can if you want to, but I don't think it just won't be necessary in this case.
It appears that the ParseFile does not have an ACL, or put another way, once the URL of the ParseFile gets out in the wild, the file is available to anybody who can make a GET http request.
I hope I'm missing something in the documentation, because this does not sound like a great idea. As best as I can understand it, this means that the URL is "protected" only by the ACL of the ParseObject that holds the reference to the ParseFile.
Perhaps it's relevant to know that I'm reading/using the .NET+Xamarin bits.
I think you've summed it up best yourself:
"protected" only by the ACL of the ParseObject that holds the reference to the ParseFile
If someone does happen to know your url for that particular file then kudos to them, because they are uniquely created, just like objectId's:
.. containing the name of the file, which is the original file name prefixed with a unique identifier in order to prevent name collisions. This means you can save files with the same name, and the files will not overwrite one another...
So in other words, the last path component will always be unique:
tfss-db295fb2-8a8b-49f3-aad3-dd911142f64f-airlines.txt
Even if you re-upload a new airlines.txt document:
tfss-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-airlines.txt
To summarize ACL:
An ACL, or Access Control List can be added to any Parse.Object to restrict access to only a subset of users of your application.
So according to Parse, it's purposes are intended for the object itself, not specific parameters of that object. As of now, they do not support say, setting a specific read/write ACL on the objects 'Title' column or 'Email' column or a specific column type, the ACL's are object or User dependent.
For those that are interested in reading more about Parses ACLs can see their resource here: http://blog.parse.com/learn/engineering/parse-security-i-are-you-the-key-master/
For example, I have a field that give user to type their domain, the user can type any domain on this, but I don't valid this domain is belong that user. Of course, I can generate a random number text file for user to upload, and when I get the random number text file, if it is match, I can just treat it as a valid domain holder. But, except from this method, is that anyway to do so? Thanks.
Options I have seen:
Have user Create a Text file in document root, check for it
Send Email to contacts listed in whois (Or other ROLE type accounts (postmaster, hostmaster, etc...), with token they need to
return
Have them create an 'A' record in their DNS that is unique and you can query for.
There really isn't any other way of telling if they have control over the domain. Using whois information isn't 100% accurate as people don't update it, or their info isn't registered to them, or is hidden behind something like domains by proxy. There is no standard information in DNS, that can tell you ownership. Since google uses the DNS method and the text file method (I think), you can probably safely assume that is a good way to verify it.
Why HttpContext.Current.User.IsInRole("Customer") returns false if the user is not logged in, I think because user is considered anonymous is this case, Correct?
Thanks
Yes, you are correct. Anonymous users cannot belong to a role.
Notice that the User object for an anonymous user is a GenericPrincipal and while it implements IPrincipal, the IsUserInRole method always returns false because there are no roles supplied when it is created by FormsAuthenticationModule.
Also notice that the User object for an authenticated user is a RolePrincipal, which queries RoleManager in IsUserInRole.
Until the user don't login to your application, application behave it as an anonymous user and this user is no known for your application.
This is the default behavior, the anonymous user has no roles.
But if it returns false you can't be sure the user is not authenticated (better use User.Identity.IsAuthenticated property).