Re: .NET CAS vs OS security

Oh yea. I was catching the SecurityException and the Exception. I forgot
that I could look for that other exception. At least that would enable an
app to give an appropriate response.

Thanks again.


"Joe Kaplan" wrote:

Unfortunately, .NET doesn't have a built in way to check ACL access to a
specific object before you try to access it. The current model is basically
to try the operation and catch the UnauthorizedAccessException.

If you want, you can P/Invoke the AccessCheck API. That's typically how to
do this type of test in advance in native code. The problem with that is
that it is possible that the access can change between the time you do the
check and the time you actually do the access, but it may be good enough for
your usage. The other thing to be careful about with AccessCheck is that
you have to know what type of access you are actually going to try to do, as
you can call AccessCheck with the wrong arguments and get misleading
results.

CAS won't come into play if your assembly is installed on the local file
system because locally installed apps have Full Trust by default. There is
absolutely no interaction between CAS permissions and OS permissions. CAS
is layered over the top of the OS security and they are based on two totally
different concepts. CAS attempts to restrict what the code itself can do
independent of the user, whereas OS security attempts to limit what the user
executing the code can do. However, CAS cannot allow you to bypass OS
security, so the code can never do more than the current user can do no
matter what CAS permissions are granted or denied.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"DXRick" <DXRick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:07E3C8AC-C926-41AE-A7AB-216448DC6381@xxxxxxxxxxxxxxxx
I decided to test an encryption program I wrote to see what the different
types of permission tests actually do when running the application from a
restricted user account. I found that if the user attempts to write to a
file at "C:\" I end up getting an application exception only at the point
the
write is attempted.

I have this to test permissions:

FileInfo encFile = new FileInfo(this.EncryptedFileNameTextBox.Text);

FileIOPermission fpWrite = new
FileIOPermission(FileIOPermissionAccess.Write, encFile.FullName);
fpWrite.Demand();
if (!System.Security.SecurityManager.IsGranted(fpWrite))
throw new System.Security.SecurityException("Nope");


So, evidently, all it is testing is the assembly's permission to perform
the
IO. CAS does not interface with the OS at all when setting up the
permission
set to grant the assembly or when an attempt is made to demand or test for
a
specific permission.

Is there a way to catch this type of situation before the actual write
attempt bumps into the OS security? I guess one could get the user's
WindowsPrinciple and test for him being an Administrator or PowerUser, and
then block access to any directory that is not in:

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)

But that would be a rather blunt way to check and may not be accurate.

Thanks.






.

Relevant Pages

  • Re: .NET CAS vs OS security
    ... CAS won't come into play if your assembly is installed on the local file ... absolutely no interaction between CAS permissions and OS permissions. ... is layered over the top of the OS security and they are based on two totally ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.dotnet.security)
  • RE: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Perm
    ... They are different types of permissions -- I was just grouping them together to distinguish them from role based security permissions, ... You could say that evidence based security is granting, and CAS is the subsystem that does the demanding if that's consistent with the ... I just tend to group the whole system together under the CAS umbrella. ... Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS? ...
    (microsoft.public.dotnet.security)
  • Re: Limiting exe permissions
    ... can't help but wonder why Microsoft didn't address this security ... > Much of the CAS effort has been around directly downloaded code (e.g.: ... > deal of complaint about the limitations that CAS already imposes. ... setting permissions of an executable should be as simple ...
    (microsoft.public.dotnet.security)
  • Re: Newbie security architecture question
    ... permissions in .Net are part of the Code Access Security system (CAS). ... > 2) Enforce security by putting up a different UI for each client based on ...
    (microsoft.public.dotnet.security)
  • Re: Newbie security architecture question
    ... permissions in .Net are part of the Code Access Security system (CAS). ... > 2) Enforce security by putting up a different UI for each client based on ...
    (microsoft.public.dotnet.framework.aspnet.security)