Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Security / January 2006

Tip: Looking for answers? Try searching our database.

CAS and FileIOPermission

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
wbarthol@gmail.com - 05 Jan 2006 02:09 GMT
I am trying to restrict an application I am writing to a single
directory (not known until run-time) to prevent any possible directory
traversal attacks (the application needs to deal with
untrusted-user-supplied paths).

What I have done is:

1. Asked CAS to give my application no permissions:

[assembly: PermissionSet(SecurityAction.RequestOptional,
Unrestricted=false)]

2. Request unrestricted FileIOPermission (is this avoidable?):

[assembly: FileIOPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]

3. When performing any action involving a user-supplied path I use
PermitOnly to drop permission to other directories:

FileIOPermission p = new FileIOPermission(PermissionState.None);
p.AddPathList(FileIOPermissionAccess.AllAccess, workingDirectory);
p.PermitOnly();

//Perform action.

FileIOPermission.RevertPermitOnly();

I'm not happy with Step 2 and 3, I'd rather the assembly only get
granted permission to the working directory, but since it's not known
until run-time (it's read from a configuration file) this does not seem
possible. Is it possible to either:

1. Have the assembly only granted access to the working directory. Or,
2. Have the assembly granted no access and then I request it when I
need it, and drop it when I'm done.

Or, is what I've done the best/only way to do this?
Dominick Baier [DevelopMentor] - 05 Jan 2006 06:35 GMT
Hi,

you don't need 1 and 2

just do the PermitOnly before the FileIO

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

> I am trying to restrict an application I am writing to a single
> directory (not known until run-time) to prevent any possible directory
[quoted text clipped - 34 lines]
>
> Or, is what I've done the best/only way to do this?
William D. Bartholomew - 05 Jan 2006 23:32 GMT
The main reason I'm doing 1 and 2 is I don't want to be granted other
privileges that aren't required.
Nicole Calinoiu - 05 Jan 2006 12:42 GMT
>I am trying to restrict an application I am writing to a single
> directory (not known until run-time) to prevent any possible directory
[quoted text clipped - 12 lines]
> [assembly: FileIOPermission(SecurityAction.RequestMinimum,
> Unrestricted=true)]

The best you can do here is to use a RequestOptional instead of a
RequestMinimum.  This would allow your assembly to run even if the machine's
CAS policy is set to only allow access to the directories that the
application actually requires.

> 3. When performing any action involving a user-supplied path I use
> PermitOnly to drop permission to other directories:
[quoted text clipped - 13 lines]
>
> 1. Have the assembly only granted access to the working directory. Or,

Not via assembly-level attributes.

> 2. Have the assembly granted no access and then I request it when I
> need it, and drop it when I'm done.

Nope.

> Or, is what I've done the best/only way to do this?

Other than using a RequestOptional for unrestricted FileIOPermission, pretty
much yes.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.