G
Guest
I have a new user in my computer titled ASP.NET Machine A..Where would it have come from and should I delete it?
N
Norman Wooten
boomer said:
It is created when you install the NET framework.. as for deleting it..
I am not sure about that.. If you can, I'd be interested..
M
Malek
You want to delete the ASPNET account ? What for ? That is the account used
by the worker process of ASP.Net, it is not a very privileged account (much
safer to use than accounts you would create yourself for the aspnet_wp,
unless you really are an very prcise in what privileges you give that
account)...
If you don't want to use ASP.Net at all, then maybe you are right in
deleting it.
If you really want to make aspnet_wp use a different account, look into
machine.config (tha's where it is stated that it uses the "machine" account
is to be used ( in <processModel userName="machine" .../>). You can modify
it to either "system", which would be a catastrophe, or to some particular
user...
by the worker process of ASP.Net, it is not a very privileged account (much
safer to use than accounts you would create yourself for the aspnet_wp,
unless you really are an very prcise in what privileges you give that
account)...
If you don't want to use ASP.Net at all, then maybe you are right in
deleting it.
If you really want to make aspnet_wp use a different account, look into
machine.config (tha's where it is stated that it uses the "machine" account
is to be used ( in <processModel userName="machine" .../>). You can modify
it to either "system", which would be a catastrophe, or to some particular
user...
have come from and should I delete it?boomer said:
N
.NET Follower
hi,
why it would be catastrophe...
i am using username =system..
and i did not face any such thing.....
why it would be catastrophe...
i am using username =system..
and i did not face any such thing.....
M
Malek
I said catastrophy, because if there is a vulnerability in some page of
yours (let people inject something), then their injected code is runing
under "system".... that is how big problems usually happen. Even if you
control all input, how do you know there is no vulnerability in the ASP.Net
worker process itself that someone would be able to exploit, and get into
your machine as "system"
yours (let people inject something), then their injected code is runing
under "system".... that is how big problems usually happen. Even if you
control all input, how do you know there is no vulnerability in the ASP.Net
worker process itself that someone would be able to exploit, and get into
your machine as "system"
N
.NET Follower
hi,
ya that s true ...
i did nt realise that ..
System means all admin rights ,is it right
and any external code
might use my code as a source to exploit my machine
so is it totallly not recommended to username =system..
in which secanario is it usefulll...
ya that s true ...
i did nt realise that ..
System means all admin rights ,is it right
and any external code
might use my code as a source to exploit my machine
so is it totallly not recommended to username =system..
in which secanario is it usefulll...
K
Kevin Spencer
I said catastrophy, because if there is a vulnerability in some page of
That's ridiculous.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
That's ridiculous.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
M
Malek
what is ridiculous ? please explain, so that I learn something ...
K
Kevin Spencer
It's ridiculous to make the blanket statement that using the System account
to run an ASP.Net application is "catastrophy." Almost all desktop
applications run under the System account. It's simply a matter of good
programming. If you own the server, there's no reason not to, as long as you
are aware of and account for the possible vulnerabilities.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
to run an ASP.Net application is "catastrophy." Almost all desktop
applications run under the System account. It's simply a matter of good
programming. If you own the server, there's no reason not to, as long as you
are aware of and account for the possible vulnerabilities.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
M
Malek
There is still a main difference between a web app and a desktop app in the
exposure to attack ...
I do not recommend using the system account or an admin account on desktop
apps either. Running with lmeast privilege is always the best aproach ...
and privilege is rarely necessary on any production machine, unless the
tasks being accomplished by the app are really priviliged tasks (backup,
admin, ...etc.). Usually, the needs of apps have to do with ACLs, not with
privilege...
making ASP.Net run with the system account is no exception, don't do it
unless you really need it (privileged tasks, like remote admin of the
machine and so on...).
Saying that you only need to account for the possible vulnerabilities is
right, however, it usally means to fix the problem !
So, you may be right that the word I used ("catastrophy") is too strong, but
it is accurate in 90% of the cases ...
I would refer to "Writing Secure Code" by Michael Howard & David LeBlanc
about the security issues of using privilege ...
When you say "If you own the server, there's no reason not to", I would
contest the assertion "you won the server", because you never really do, at
least, you only own it until somebody else hacks it... unless your code is
perfect (can human work ever be ?). My point here is that you should never
assume that you are capable of stopping exploits 100%...
exposure to attack ...
I do not recommend using the system account or an admin account on desktop
apps either. Running with lmeast privilege is always the best aproach ...
and privilege is rarely necessary on any production machine, unless the
tasks being accomplished by the app are really priviliged tasks (backup,
admin, ...etc.). Usually, the needs of apps have to do with ACLs, not with
privilege...
making ASP.Net run with the system account is no exception, don't do it
unless you really need it (privileged tasks, like remote admin of the
machine and so on...).
Saying that you only need to account for the possible vulnerabilities is
right, however, it usally means to fix the problem !
So, you may be right that the word I used ("catastrophy") is too strong, but
it is accurate in 90% of the cases ...
I would refer to "Writing Secure Code" by Michael Howard & David LeBlanc
about the security issues of using privilege ...
When you say "If you own the server, there's no reason not to", I would
contest the assertion "you won the server", because you never really do, at
least, you only own it until somebody else hacks it... unless your code is
perfect (can human work ever be ?). My point here is that you should never
assume that you are capable of stopping exploits 100%...
K
Kevin Spencer
HiMalek,
If you want to use a less extreme word than "catastrophy", I certainly won't
call it "ridiculous."
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
If you want to use a less extreme word than "catastrophy", I certainly won't
call it "ridiculous."
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.