>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 |