<div dir="ltr">On Thu, Oct 16, 2008 at 1:46 PM, Brian Reese <span dir="ltr"><<a href="mailto:breese@boston-engineering.com">breese@boston-engineering.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br>
>Hi Brian,<br>
<br>
>Brian Reese wrote:<br>
>> 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:<br>
<br>
>Nice to read. You might add a note to the Testimonials on<br>
<<a href="http://www.wpkg.org/" target="_blank">http://www.wpkg.org/</a>> :-)<br>
<br>
<br>
>> 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 :)<br>
<br>
>SYSTEM is actually an account which has even a higher privilege level<br>
than Administrator accounts have. Check the properties/security of the<br>
%SystemRoot% folder for example. However you cannot log in to a system<br>
using the SYSTEM account. It is mainly for services and background<br>
system processes.<br>
<br>
>If anybody is able to attack and take over the process context of an<br>
application which runs with SYSTEM privileges, then he actually owns the<br>
system with full control. But it's quite hard to do that usually. In<br>
general only system services are running with SYSTEM privileges. To run<br>
a service with SYSTEM privileges you do not have to enter a password.<br>
This is still no security breach since only administrators are allowed<br>
to modify/create services. In addition nobody knows the SYSTEM user<br>
password (does it have one?) and of course nobody can log in<br>
interactively using this account.<br>
<br>
>So it can become a security breach only in case somebody manages to<br>
attack a running WPKG service and manages to insert some code which is<br>
then executed with SYSTEM privileges (by buffer overflows or similar).<br>
This risk is quite low with WPKG as it allows to delay login (no user<br>
interaction possible before the service finishes) and it even allows to<br>
exit the service (no WPKG client process with SYSTEM privileges running<br>
any more) after the job has been finished. So no attack vector possible<br>
here.<br>
<br>
>However there is a possibility to break security using WPKG. If you do<br>
not properly set access rights to the WPKG software share (where XML<br>
files and installers are stored) then an attacker might insert his own<br>
packages and execute them on the workstations. As wpkg.js runs on the<br>
local workstation invoked by WPKG client it inherits SYSTEM privileges<br>
as well. Inserting a "dummy" package which is running an FTP server for<br>
example instead of an installer will allow an attacker to run that FTP<br>
server with SYSTEM privileges on client computers.<br>
<br>
>The same applies to any other software distribution system. If the<br>
attacker manages to insert custom packages to the software server they<br>
are executed with at least administrator privileges since this<br>
privileges are required to install software.<br>
<br>
>However usually (as recommended) you should read software packages and<br>
XML files only from a read-only share (use WPKG client user/password to<br>
connect using a read-only user). Use another user to update XML files<br>
and software packages. The password of the read/write update user should<br>
be kept secure. This prevents intruders to insert unwanted packages and<br>
the system is considered to be secure.<br>
<br>
>By the way: User names and passwords are stored in a secure locker<br>
within Windows by WPKG client, there is no easy way to get to this<br>
passwords.<br>
<br>
<br>
>So I hope that clarifies some things.<br>
<br>
<br>
>> 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.<br>
<br>
>Yes, newest versions of WPKG client support this feature (however I've<br>
never used it yet). But I am using the latest 1.3 pre-release package<br>
since quite a while now without any problems (not using the on-shutdown,<br>
nor the logon delay feature).<br>
<br>
>Personally I've seen too many problems with the logon delay feature and<br>
I hate to keep users waiting by a "please wait" pre-logon screen. I am<br>
operating a (Samba-) domain and found that running WPKG at startup in<br>
parallel to the network logon is absolutely fine with me. Usually WPKG<br>
finishes before the user enters his password or at least before the<br>
roaming profile is fetched from the server and the desktop loads. So no<br>
conflicts with running applications. Some installers also support<br>
scheduling file-replacements of in-use files for next reboot, so even if<br>
the user manages to start an application which WPKG is trying to upgrade<br>
in the background the installation will succeed (latest effective after<br>
next reboot). In worst case the upgrade fails, then WPKG will know it<br>
failed and try on next reboot - no big deal, up to now every<br>
installation succeeded, even without logon delay.<br>
<br>
>Just for information: I am operating a site with Windows XP machines as<br>
well as my home site with 3 Vista-64 machines and an XP-32 box.<br>
<br>
br,<br>
Rainer<br>
<br>
</div></div>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.<br>
<font color="#888888"><br>
-Brian<br>
</font><div><div></div><div class="Wj3C7c">-------------------------------------------------------------------------<br>
wpkg-users mailing list archives >> <a href="http://lists.wpkg.org/pipermail/wpkg-users/" target="_blank">http://lists.wpkg.org/pipermail/wpkg-users/</a><br>
_______________________________________________<br>
wpkg-users mailing list<br>
<a href="mailto:wpkg-users@lists.wpkg.org">wpkg-users@lists.wpkg.org</a><br>
<a href="http://lists.wpkg.org/mailman/listinfo/wpkg-users" target="_blank">http://lists.wpkg.org/mailman/listinfo/wpkg-users</a><br>
</div></div></blockquote></div><br>I must say there was a lot of great information there that I never
knew. Perhaps a suggestion to move this to the documentation wiki? Not
certain how open the wiki is to public editing. Thanks Rainer.<br>
<br>
landersk<br></div>