Re: limited account permission and writing to system areas?
- From: Dominick Baier <dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 15 Mar 2007 07:12:36 +0000 (UTC)
you shouldn't write to Program Files or HKLM in components that are run by normal users...Use their profile and HKCU instead.
-----
Dominick Baier (http://www.leastprivilege.com)
Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)
I'm dealing with a security problem in a global assembly that I've
created and need some guidance.
The assembly is used by many different client programs, so the
installer of each one installs it in the Global Assembly Cache (which
may end up with multiple versions in a side-by-side fashion).
The assembly reads and writes to a file in the C:\Program Files\Common
Files\<CompanyName> sub-folder.
It also writes to a registry key in HKLM\Software\<CompanyName\...
sub-key.
Both of these happen during both installation and run-time operation.
In terms of reducing my dependency on priviledged operations... I
could theoretically get rid of the latter (i.e. the reg key write),
because it only writes the name of the file that I created with the
former (i.e. in the <CommonFilesFolder>\<CompanyName\... subfolder).
That is, I could fix the filename to one specific filename and always
assume that one filename, so I wouldn't need to update the registry
key. However, since the assembly is used by different users, I don't
know where else to put it besides somewhere that is non-user-specific.
I suppose that putting it in <AppDataFolder> would be more appropriate
than <CommonFilesFolder>, but I don't think that will solve my
problem. And once it is in a non-user-specific location, I have
trouble accessing that location to write a file on a limited account.
I've read (without much comprehension, unfortunately) about security
attributes that I can add to my assembly indicating what kinds of
permissions I need. However, I've seen things like:
[assembly:FileIOPermissionAttribute(SecurityAction.RequestMinimum,
All="C:\\example\\sample.txt")]
Is this for real? I can only use this if I hard-code the path to the
file I want access to? That can't be the way this really works, is it?
At the very least, can't we abstract some of the path (c.f.
Environment.SpecialFolder.CommonProgramFiles rather than "C:\\Program
Files\Common Files...").
The assembly *installs* okay because we encourage users to run the
setup with 'Run as Administrator' (in Vista, and as Administrator on
XP), without which, we couldn't install in the global assembly cache.
I'm hoping that I can specify some attributes or even run-time
requests that basically say, "If the user installs this as an
administrator, then whenever this code is used, it will automatically
be allowed to write to that file system location".
Is such a thing possible?
Thanks,
Bob
.
- References:
- limited account permission and writing to system areas?
- From: Bob Eaton
- limited account permission and writing to system areas?
- Prev by Date: Re: WindowsIdentity - Invalid token; it cannot be duplicated
- Next by Date: Removing the "Inherit permissions from parent" from an NTFS folder using System.Security.AccessControl
- Previous by thread: limited account permission and writing to system areas?
- Next by thread: what encoding does system.xml.xmldocument.save(string path) use to save the xml document if there is no <?xml... in the front of the xml document?
- Index(es):
Relevant Pages
|
