Re: Forcing Process to Run With Ordinary User Authority

"W" <> wrote in message
news: ...
> Is there a way to force a program to run in a security context of an
> ordinary user when invoked from the command line of an administrator
> login?
> I don't want to have to supply any credentials. The use case is a
> Scheduled Task that runs as SYSTEM, but which invokes browser instances to
> the screen each day (to check on data on various web sites).
>
> Since the security shift is from administrator / SYSTEM level to an
> ordinary
> user context (i.e., a member of local Users group), I would really hope
> that
> it would not be necessary to expose a credential in the script of the
> batch
> file that runs as a Scheduled Task.

There are a few potential issues you should be aware of:

1. when two instances of IE are started under alternate credentials (using,
for example, runas), the second one detects a running instance, and
piggy-backs onto it, inheriting a security context different from what you
might expect. The best approach is generally to use runas only for
increasing the privilege level, rather than lowering it.

2. for security reasons, runas was designed to accept the alternate password
interactively. third-party tools are available that allow a non-interactive
process to simulate a runas by embedding the password somewhere, often with
various levels of encryption. IMHO, it can be very difficult to prove that
these methods are as secure as you would like, so best practice is to avoid
them.

One possibility would be to create a separate script to do what needs to be
done under non-privileged credentials and create a task for it based on
those credentials. The privileged SYSTEM task would then simply start the
other task. If it needed to pass it information, this could be done by
writing it into a file that the other task would read from.

/Al

"Al Dunbar" <> wrote in message
news:...
>
> "W" <> wrote in message
> news: ...
>> Is there a way to force a program to run in a security context of an
>> ordinary user when invoked from the command line of an administrator
>> login?
>> I don't want to have to supply any credentials. The use case is a
>> Scheduled Task that runs as SYSTEM, but which invokes browser instances
>> to
>> the screen each day (to check on data on various web sites).
>>
>> Since the security shift is from administrator / SYSTEM level to an
>> ordinary
>> user context (i.e., a member of local Users group), I would really hope
>> that
>> it would not be necessary to expose a credential in the script of the
>> batch
>> file that runs as a Scheduled Task.
>
> There are a few potential issues you should be aware of:
>
> 1. when two instances of IE are started under alternate credentials
> (using, for example, runas), the second one detects a running instance,
> and piggy-backs onto it, inheriting a security context different from what
> you might expect. The best approach is generally to use runas only for
> increasing the privilege level, rather than lowering it.

addendum: the reason for this is that it is very easy to detect when an
attempt to use a higher level of privilege has failed than an attempt to use
a lower level. If you try to run a privileged application (ADU&C, for
example) from a non-privileged account using runas, if the alternate account
lacks the required privilege level, you will be unable to use the
application for actions requiring privilege (create accounts, set password).
If you open a browser from a privileged account using runas, your success
would not prove that you were running at the least privilege required.

/Al

> 2. for security reasons, runas was designed to accept the alternate
> password interactively. third-party tools are available that allow a
> non-interactive process to simulate a runas by embedding the password
> somewhere, often with various levels of encryption. IMHO, it can be very
> difficult to prove that these methods are as secure as you would like, so
> best practice is to avoid them.
>
> One possibility would be to create a separate script to do what needs to
> be done under non-privileged credentials and create a task for it based on
> those credentials. The privileged SYSTEM task would then simply start the
> other task. If it needed to pass it information, this could be done by
> writing it into a file that the other task would read from.
>
> /Al
>
>

"W" <> wrote in message
news: ...
> I dislike using stored credentials for ordinary users is Scheduled Tasks
> since apparently the password gets stored in clear text somewhere in
> memory
> that other services can access. I read several scenarios for intrusion
> where an intruder gains access to a service and then is able to dump
> passwords of all users running in a Scheduled Task.

If the password is stored in clear text, then I would be at least as
concerned about using the credentials of privileged accounts to run
scheduled tasks. I rather suspect that a more secure method is used, but I
have no info on it.

Note that when I suggested creating a task running on "non-privileged
credentials", I was not suggesting using an actual user account. Just using
an account that is as limited as possible, but that can get the job done.


/Al

> --
> W
>
> "Al Dunbar" <> wrote in message
> news:...
>>
>> "W" <> wrote in message
>> news: ...
>> > Is there a way to force a program to run in a security context of an
>> > ordinary user when invoked from the command line of an administrator
>> > login?
>> > I don't want to have to supply any credentials. The use case is a
>> > Scheduled Task that runs as SYSTEM, but which invokes browser instances
> to
>> > the screen each day (to check on data on various web sites).
>> >
>> > Since the security shift is from administrator / SYSTEM level to an
>> > ordinary
>> > user context (i.e., a member of local Users group), I would really hope
>> > that
>> > it would not be necessary to expose a credential in the script of the
>> > batch
>> > file that runs as a Scheduled Task.
>>
>> There are a few potential issues you should be aware of:
>>
>> 1. when two instances of IE are started under alternate credentials
> (using,
>> for example, runas), the second one detects a running instance, and
>> piggy-backs onto it, inheriting a security context different from what
>> you
>> might expect. The best approach is generally to use runas only for
>> increasing the privilege level, rather than lowering it.
>>
>> 2. for security reasons, runas was designed to accept the alternate
> password
>> interactively. third-party tools are available that allow a
> non-interactive
>> process to simulate a runas by embedding the password somewhere, often
> with
>> various levels of encryption. IMHO, it can be very difficult to prove
>> that
>> these methods are as secure as you would like, so best practice is to
> avoid
>> them.
>>
>> One possibility would be to create a separate script to do what needs to
> be
>> done under non-privileged credentials and create a task for it based on
>> those credentials. The privileged SYSTEM task would then simply start the
>> other task. If it needed to pass it information, this could be done by
>> writing it into a file that the other task would read from.
>>
>> /Al
>>
>>
>
>