[wpkg-users] Question about system account

[Brian Reese]

>Hi Brian,

>Brian Reese wrote:
>> First off I'd like to say that WPKG is pretty nice and helps us solve a bunch of issues. I've recently been trying to get more advanced with my configuration, and put it into production with all clients, instead of IT just using it to rebuild or reconfigure machines. I have a couple questions:

>Nice to read. You might add a note to the Testimonials on
<http://www.wpkg.org/> :-)


>> With regards to the SYSTEM account, I'm not certain about how windows handles system account privileges, but it seems like to me that using the non-passworded  SYSTEM account could be a security breech. I was told it isn't and I assume you guys wouldn't set the default to something that would have issues, but if someone could enlighten me, I'd appreciate it :)

>SYSTEM is actually an account which has even a higher privilege level
than Administrator accounts have. Check the properties/security of the
%SystemRoot% folder for example. However you cannot log in to a system
using the SYSTEM account. It is mainly for services and background
system processes.

>If anybody is able to attack and take over the process context of an
application which runs with SYSTEM privileges, then he actually owns the
system with full control. But it's quite hard to do that usually. In
general only system services are running with SYSTEM privileges. To run
a service with SYSTEM privileges you do not have to enter a password.
This is still no security breach since only administrators are allowed
to modify/create services. In addition nobody knows the SYSTEM user
password (does it have one?) and of course nobody can log in
interactively using this account.

>So it can become a security breach only in case somebody manages to
attack a running WPKG service and manages to insert some code which is
then executed with SYSTEM privileges (by buffer overflows or similar).
This risk is quite low with WPKG as it allows to delay login (no user
interaction possible before the service finishes) and it even allows to
exit the service (no WPKG client process with SYSTEM privileges running
any more) after the job has been finished. So no attack vector possible
here.

>However there is a possibility to break security using WPKG. If you do
not properly set access rights to the WPKG software share (where XML
files and installers are stored) then an attacker might insert his own
packages and execute them on the workstations. As wpkg.js runs on the
local workstation invoked by WPKG client it inherits SYSTEM privileges
as well. Inserting a "dummy" package which is running an FTP server for
example instead of an installer will allow an attacker to run that FTP
server with SYSTEM privileges on client computers.

>The same applies to any other software distribution system. If the
attacker manages to insert custom packages to the software server they
are executed with at least administrator privileges since this
privileges are required to install software.

>However usually (as recommended) you should read software packages and
XML files only from a read-only share (use WPKG client user/password to
connect using a read-only user). Use another user to update XML files
and software packages. The password of the read/write update user should
be kept secure. This prevents intruders to insert unwanted packages and
the system is considered to be secure.

>By the way: User names and passwords are stored in a secure locker
within Windows by WPKG client, there is no easy way to get to this
passwords.


>So I hope that clarifies some things.


>> Also, I read somewhere in this email group that one of the new versions allows WPKG to run upon shutdown instead of startup, is it version 1.3.5 and when will that be considered "stable". And are you guys planning to support the web interface? Which by the way looks nice but I haven't gotten into yet. Thanks for any help.

>Yes, newest versions of WPKG client support this feature (however I've
never used it yet). But I am using the latest 1.3 pre-release package
since quite a while now without any problems (not using the on-shutdown,
nor the logon delay feature).

>Personally I've seen too many problems with the logon delay feature and
I hate to keep users waiting by a "please wait" pre-logon screen. I am
operating a (Samba-) domain and found that running WPKG at startup in
parallel to the network logon is absolutely fine with me. Usually WPKG
finishes before the user enters his password or at least before the
roaming profile is fetched from the server and the desktop loads. So no
conflicts with running applications. Some installers also support
scheduling file-replacements of in-use files for next reboot, so even if
the user manages to start an application which WPKG is trying to upgrade
in the background the installation will succeed (latest effective after
next reboot). In worst case the upgrade fails, then WPKG will know it
failed and try on next reboot - no big deal, up to now every
installation succeeded, even without logon delay.

>Just for information: I am operating a site with Windows XP machines as
well as my home site with 3 Vista-64 machines and an XP-32 box.

br,
Rainer

Thanks so much Rainer, this information is exactly what I was looking for, I had some trouble finding consistent information via google. Looks like im going to move to SYSTEM and have my users access the share with the lowest possible privileged readonly account. Normally I don't submit testimonials but since you put the time into providing a detailed response I will happily comply and add mine to the list :) Once again, I appreciate the help.

-Brian