Re: Why Users dont have write rights to the %windir%\TEMP folder




"Dave Warren" <dave-usenet@xxxxxxxxxxxxxxxx> wrote in message
news:eerg059n0rvbmhh824lvc873agite7vl2t@xxxxxxxxxx
In message <mn.5afb7d95bc9da599.70874@xxxxxxxxxxxxxxxxxx> Eric
<Eric_m@xxxxxxxxxxxxxxxxxx> was claimed to have wrote:

Hello,

everything is in the title ;-)

In future, please put the entire content of your post in the body of the
post, and put only a descriptive "subject" in the subject line.

Why users don't have the write access to the c:\windows\temp folder
(when Power Users have this access).

By default, power user access is somewhere between administrator and user.
This allows you to give some regular users rights that will allow them to
assist other users. IMHO, this should be done by having special "power user"
accounts that are NOT to be used for other than assisting other users (i.e.
no internet browsing or running corporate applications). Ideally, they
should also have the basics of security explained to them so they don't go
and do something stiupid.

In my organization we have about 20,000 regular user accounts, perhaps 300
accounts having admin access on selected workstations and, in some cases,
servers. The number of "power users" of any type can be counted on the
fingers of zero hands.

Is there a security reason for that ?

Yes.

I will appreciate to have technical information about that as we have
an application that needs to let "Users" to have write access on this
folder and I will like to see if it is acceptable in terms of security.

That's not the correct location for temporary files, any and every file
a user needs to write should be in their own profile directory.

The security risk here is that by allowing applications to use a central
temporarily file storage, it potentially allows a malicious user to
place a file here that will exploit a buffer overrun or other similar
bug in an application installed on the machine to cause that application
to do something unexpected.

An example I've seen in real life:

<snipped: an excellent, real-life example>

Unfortunately, the OP is hooped, unless this is an in-house developed
application that could be modified to comply more closely with security best
practices.

If you do proceed, what I would recommend is that you create a domain-level
security group that will contain all users of the application, and give
change access to the TEMP folder only to that group. Tighter control could
have such a group for each workstation, such that users of the application
would only have this access on the system they normally use for the purpose
rather than on every workstation.

/Al


.



Relevant Pages

  • Paradigms II
    ... Secure Systems Revisited ... Performing the following very basic security evaluation on your system ... (server or workstation); however, they can be easily adapted to any other ... control over that information. ...
    (comp.security.misc)
  • Re: Paradigms II
    ... > are not about trying to circumvent security. ... > (server or workstation); however, they can be easily adapted to any other ... > to have at least a vague idea what security, and a secure environment, ...
    (comp.security.misc)
  • Re: Event ID 5719: No Windows NT or Windows 2000 Domain Controller is available for domain .
    ... In my experience what you have done with security policy should ... The workstation gets its networking information from DHCP that, ... updates DNS. ... I don't believe the problem to be at the server end though. ...
    (microsoft.public.win2000.security)
  • [UNIX] Bad Temporary File Handling in GNAT
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... GNAT) handles temporary files in an unsafe manner, ... The patch below replaces the calls to tmpnamor mktempwith ones to ...
    (Securiteam)
  • Re: Upgraded from SBS2K to 2K3: Connectcomputer Wont on XP client
    ... Could it be security issue? ... > Decided to upgrade the office network for practice. ... > workstation, a fully patched XP pro which had been working flawlessly on ... the server shows them (but ...
    (microsoft.public.windows.server.sbs)