I need to create a program that will run under a common user profile but
which will need to be able to perform some file IO tasks that the user
doesn't have the rights to perform.  I can get this done with impersonation
but I can't figure out how to avoid storing the password in plain text inside
the executable, which is not acceptable.  I know this has been asked before
but I can't find an answer anywhere.  I was hoping that somehow code access
security could be set up to simply give the application its own set of
rights.  Is that not possible?  Is that not what code access security policy
is all about?  This is the first time I've tried anything like this, so any
help would be very much appreciated.  Thanks.

A few other options:

1.  Ask the user.
2.  Store the password elsewhere.
3.  Call into another component (e.g.: COM+ application) running under
another user context.

My own general preference is for #3, but the best choice for your
application will depend on quite a few details like target OS version(s),
tolerable user experience, etc.  Storing the password anywhere (encrypted or
not) is usually the riskiest option and should probably be avoided if at all
possible.


No, quite the opposite.  The main goal of CAS is to allow restriction, not
elevation, of code permissions beyond the permission set granted to the
user.


Show quoteHide quote

Thank you for your quick respose.  I am interested in trying your suggestion
#3, as asking the user is not possible, and I have not yet found a place I am
comfortable storing credentials. 

However I am not sure of how to go about this.  The target OS is XP Pro SP2.
I don't understand what I need to do to access a component in another user
context.  Do you mean a component running on a different machine, because I
thought my initial problem wass trying to get something to run in another
user context.  Is this something I can do with remoting?  If you have any
examples or additional information you could point me to it would be very
helpful.  Thanks very much.

April 11, 2005

    Code access security will grant the assembly its own rights, BUT the
user must also be granted the rights as well. Therefore if the assembly can
access MyFile.txt by CAS, it still cannot if the user cannot access
MyFile.txt. It is the same if the user is allowed to access the file, but
the assembly isn't. Hope this might clear a little confusion and calling a
seperate application that is under a different account is a good idea! HTH

                                                         Joseph MCAD



Show quoteHide quote

<snip>
Not necessarily.  Are the files in question located on the machine on which
your application will be running or elsewhere on the network?


There's no need to introduce remoting if it's not otherwise useful.
However, if your application is already using remoting, it could be helpful
wrt the file IO if the files in question are located on the remoting server.


Show quoteHide quote

The files are located on the same machine.

Show quoteHide quote

In that case, a COM+ ("Enterprise Services" in .NET lingo) server
application configured to run as a user with appropriate permissions on the
file(s) in question would probably be your best bet.  Unfortunately, I don't
know of any samples that are targeted at this type of scenario.  This seems
like a pretty big hole to me, so I'll try to write one up over the next week
or so...

In the meantime, it would probably be a good idea to get up to speed on
general enterprise services issues.  The general guide to developing
serviced components can be found at
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconwritingservicedcomponents.asp.
Some additional security considerations are documented at
http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh17.asp.



Show quoteHide quote

Thanks, Nicole, you've been very helpful.  I will read up on the serviced
components and security articles and look forward to any sample you may post.

Show quoteHide quote

Sorry the sample is taking so long.  I've been down with the flu for the
past week, and you probably wouldn't want to read any of the incoherent
ramblings I managed to generate during that time anyway. <g>  I'll try to
have it ready for you soon...


Show quoteHide quote

Hmm... Before I spend more time on the guide/sample, just wanted to check if
you're still listening and actually still want it?


Show quoteHide quote

Show quote Hide quote The thing that you should be aware about with #3 is that COM+ stores
passwords unencrypted in LSA secrets. Administrators can simply read clear
text password from LSA secret associated with your COM+ application. So, for
COM+ - the recommendation would be to use some account that has logon as
batch job right (or logon as service if you run your COM+ application as
service) and no logon locally rights for being sure that nobody uses it as
his/her normal logon account.

-Valery.
http://www.harper.no/valery

<snip>
Well, "simply" might be a bit of an exaggeration. <g>  In this particular
case, that's not necessarily a problem.  Administrators will be able to read
and modify all local files anyway, so they presumably gain nothing from
learning the password of the identity user for the COM+ application.  Of
course, if the account is incorrectly set up (e.g.: domain account used or
same password used on all machines), a local admin on one machine could gain
information that might allow him to access resources inappropriately on
another machine.  However, this is really quite easy to avoid.  For example,
when deploying to client machines, a randomly password can be assigned to a
newly generated local account by the installer.


While I agree that it's important to apply such restrictions to accounts
used in this way, once the account exists, there's no way to ensure that it
can't be misused by a sufficiently determined attacker that has managed to
acquire the account credentials.  However, this approach at least removes
the need for the password to be accessible to an account that does not have
the required permissions for the targeted file I/O operation.  If there's a
better approach that would offer a tolerable user experience, I'd love to
hear about it...


Show quoteHide quote

Show quote Hide quote Well, "simply" might be a bit of non-understanding <g>. Being able to change
the password is not the same as being able to read the clear text password.
Think of setting COM+ application to use identity of existing user... Do I
need to say any more?...

This especially important if we need access to domain resources and start
using domain accounts for COM+ services. In that case, when you setup your
COM+ account some service account that doesn't have rights to logon locally
in your domain (f.e. deny logon locally set in domain policy), and after a
while you discover this account in audit alerts to sensitive resources - you
know where to look - rogue administrator. When real user account appears in
audit alerts - pure guy will get his/her portion of unnecessary troubles,
but to look for rogue administrator isn't always obvious in such cases.


-Valery.
http://www.harper.no/valery

<snip>
An admin could do something silly like this with an empty COM+ application
too.  An ignorant admin doesn't need developer help to wreak havoc.


In this particular scenario, local resources are the only targets.  If
network resources were targeted, I would not recommend a COM+ application on
the client as the first choice approach.


A local admin could do all sorts of horrible things.  For example, he could
substitute his own code to run as the COM+ component under the previously
established application identity.  This is the first of several reasons why
I would avoid accessing network resources directly from a COM+ server
running with elevated privileges on a client machine.  Accessing such
resources from code running in the more controlled/controllable environment
of a server is generally quite a bit safer.

And what's your point? Are we talking here about competencies or about the
facts?

I'm just warning that COM+ and DCOM stores password in unencrypted form in
LSA secret. If I remember it correctly COM+/DCOM LSA secrets are named as
APPID:{APPID_GUID_HERE}. You can use any version of lsadump for that, or you
can use my very simple PrintSecret utility that I wrote back in 1997 (you
can find PrintSecret together with its source code on my website - just
following "Relics from DCOM era" link). It is not like "sky is falling"....
more over - it is not any problem at all if alternative credential of COM+
application are used correctly. And that "correct using" first of all means
a separate account that is not used for normal user login (i.e. has "deny
logon interactively" right).

BTW: COM+ applications are used for accessing domain resources much more
often than you probably think ( looking at your arguments in your prev post
makes me think that you think that .... :-) ). Database connections are one
of the most usual examples. And another btw: during Windows DNA time it was
one of the major advises - to use Integrated Windows Authentication on
Database Server on the back-end; in the middle tier - to run COM+ component
with account that has necessary access rights to the databases (and
databases are usually running on separate computers).




-Valery.

http://www.harper.no/valery

Show quote Hide quote To be honest, I really don't know anymore.  I read your point as suggesting
that the alteration of the identity account for an existing COM+ application
could cause exposure of a human user's password.  I don't disagree with
this.  However, I do find this to be an unlikely activity, particularly if
the application installer and/or documentation discourages it.  If an admin
were to do this, it would presumably be due to ignorance and/or incompetence
but, quite frankly, I would expect such an admin to cause all sorts of other
damage before he got around to messing with COM+ application identities.


Since you've chosen to ignore the response I gave to this issue as raised in
your first post in this thread, I don't know quite what else to say on the
topic.  I still think that it's not really a stumbling block for the
particular scenario proposed by the original poster, and that alternate
approaches offer a less generally acceptable security vs useability
trade-off.  If you have a better solution in mind, I'd be happy to hear
about it.


IMO, there's an even more compelling reason for using an
application-specific account: least privilege.  Even if the passwords were
not exposed, it would still be preferable to restrict the identity account's
permissions to only the resources that are actually used by the application.
Interactive logon is just one of many privileges such an account would not
need.


Then you've badly misinterpreted my previous comments.  I've already stated
that I agree with you that a COM+ application running on a client machine
should not use the identity of a domain user (and for reasons that go beyond
potential password exposure).  If it seems that I'm trying to steer the
discussion away from the topic of access to network resources, I am <g>, but
only because I'm trying to stay focused on OP's question, which involves
access to local resources only.  IMO, this particular scenario is often
poorly handled (often by granting direct access to the resources in question
to too large a user pool), and I believe that it merits separate
consideration.


While this topic has some potentially interesting meat on its bones, it's
getting further (network resources) and further (accessed from another
server) away from the original question in this thread.  Given that I've
promised a sample to OP, I'm going to try to defer any off-topic discussion
until after I've actually delivered on that promise... <g>

Show quote Hide quote Then you read my point wrong. My point is just to point to a mere fact that
COM+ and DCOM stores password in unencrypted form in LSA secret. I'm
repeating it for the third time now and hope that you read my point this
time.

I.e. it was an informational post. I believe that this kind of information
has value for the readers of this group, including OP. Since I'm not
suggesting anything to OP (and I must admit that I didn't even read original
question), I chose not to respond to any discussion concerning that concrete
scenario.

Nicole, you look as a very smart person, but why is that negative reaction
on something that just slightly looks as an argument to you? I've deleted
parts of your responses because:

- I was just presenting some information (not quite widely know) to the
group and OP;

- I was not arguing to the major part of what you were saying (I thought it
was clear from my posts);

- I had no intention to discuss any particular scenario.

- and that's why I deleted parts of your post that were irrelevant to my
responses.



Once again - I'm not arguing to your suggestions to OP in that concrete
scenario (I must admit that I didn't read your suggestions carefully enough
to start arguing).

Nicole, I truly respect your knowledge and your willingness to help online
peers, and therefore I want to add one more thing here (even risking to
sound tutoring): being a smart person doesn't mean that you have to defend
yourself from anything that looks like an argument to you. But it does mean
to know that there always will be people who knows more and who is smarter
than your (or me, or anyone else who we ever got accustomed with).  So,
please, get over it.



-Valery.

http://www.harper.no/valery



P.S. Just in case if my poor knowledge of English prevented from expressing
myself clearly this time too - this post was supposed to be polite and I
didn't mean it to be insulting or challenging in any way. If any part of my
post could be interpreted otherwise, my apologies.

Cannot open log for source {0}. You may not have write access. (Access right wanish after a while)
local admin security question
AzMan threading problems
How to run aspnet with system account
web application can not access event log
Difference between VS2003 / VS20005 causes CRYPTO BAD DATA excepti
Cannot run program from network drive
Rijndael decryption succeeds SOMETIMES
Help How to add publisher condition ??
Question regarding in Forms authentication