.NET CAS vs OS security

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

DXRick - 09 Mar 2007 00:39 GMT

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.

Reply to this Message

Joe Kaplan - 09 Mar 2007 05:45 GMT

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.

Signature

Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

>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
[quoted text clipped - 31 lines]
>
> Thanks.

Reply to this Message

DXRick - 09 Mar 2007 07:01 GMT

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.

> 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
[quoted text clipped - 56 lines]
> >
> > Thanks.

Reply to this Message

.NET CAS vs OS security

Free Magazines