Here's my reply to George... figure I might as well share my thoughts with the rest of y'all and see what ya think. ---------- As with any executable that may run as a system service, it would be nice to have some installation routine check to see if it's on an NTFS partition, and if so, make sure that wherever the EXE file ends up, it's read/write for only administrators, read-only for everyone else.
Otherwise, someone with a non-admin logon account on that machine could modify the EXE with their own, reboot, and that EXE of theirs runs under local system and can do naughty things. That's why, in general, most software that runs as a service will copy it's files into the system32 directory where, by default, the permissions are just as described. If it's a FAT partition, then it really doesn't matter because any service could be modified. For that matter, you could modify a file on an NTFS partition by using any of the NTFS read/write programs like NTFSDOS or ERD Commander, etc. etc. But the point is not to make it easy on someone. If they had a tool like NTFSDOS or ERD Commander, they could do whatever they wanted anyway. :) Otherwise, as long as the code is working to prevent launching multiple instances, then I don't see a problem with it overall. You could even have the service run as a user account instead of local system, although that allows for other possible problems if network access is restricted by user account according to policies or single sign on firewall solutions. I'd guess that in those cases, even local system would have problems, so it may be worth looking into... create a local, non-admin user account and have the service run as that user. Common practice, especially for web services, .NET stuff, etc. My $0.02 worth. Aaron PS - In re: to the comments below... Guest is disabled by default, so that's probably the least of the concerns. :) > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:mersenne-invalid- > [EMAIL PROTECTED]] On Behalf Of Jeff Woods > Sent: Wednesday, June 26, 2002 8:28 AM > To: [EMAIL PROTECTED] > Subject: Re: Mersenne: Prime95 as an NT/2000/XP service > > At 12:46 AM 6/26/02 -0400, you wrote: > > >I've spent a few days fighting with Windows and MFC to make Prime95 run > as > >a true > >Windows NT Service. That is, when you check the "Start at Bootup" menu > >choice, > >prime95 is installed as a service. At next bootup it starts before > anyone > >logs in. > >At first login, the familiar red icon appears in the system tray, and > >prime95 keeps > >running even when you log off. > > > >This question is for the serious NT sysadmins out there: Given that > Microsoft > >strongly discourages NT services having a GUI interface, are there any > >problems > >or security issues I need to worry about? A GUI service must run under > >the Local > >System account. You can still use Hide Icon to make the service > virtually > >invisible to all users. > > Let's say Joe User is logged on as "Joe", with "Guest" permissions. > > Do you REALLY want him to have access to a GUI that is running as > LocalSystem (in essence, as Administrator)? > > No, you don't. While your app MAY be secure, most admins won't want to > give that kind of "break" to someone trying to hack the box, and any > serious admin is simply going to download the "True Service" version, and > run that. > > >Even if there are problems, I think this will work well for naive home > >users running > >WinXP with multiple user accounts. My hope is to eliminate the NTsetup > and > >NTPrime programs with this feature. > > Yes, with WinXP, it might offer an advantage. But you asked for the view > from a serious NT admin, and I don't want to see the separate version go > away, not if it means having to run a LocalUser app, and giving access to > it to Guest users.... > > ________________________________________________________________________ _ > Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
