> One question - should I create a new jira, or use an > existing, to submit the patch ?
I don't think there's an exising JIRA for adding service capability for the broker, so unless you have found one, please enter a new one. Thanks, -Steve > On Fri, Apr 2, 2010 at 11:34 AM, Steve Huston > <[email protected]> wrote: > > > Thanks for checking into best practices here, Kerry! > > > > -Steve > > > > > -----Original Message----- > > > From: Kerry Bonin [mailto:[email protected]] > > > Sent: Friday, April 02, 2010 11:33 AM > > > To: [email protected] > > > Subject: Re: Access to qpidd original arg list from {platform > > > specific}QpiddBroker.cpp ? > > > > > > > > > FWIW, I've been doing some reading, and talking to > friends who are > > > still active on the exploit side of the security world, > and they've > > > convinced me the default user should be NetworkService. Short > > > version is a) it is the official Microsoft recommendation, and b) > > > all the attack plans post process injection / remote > execution begin > > > with privilege escalation, so its best if your process > starts with > > > the lowest possible local privileges. In the real world once > > > process injection / remote execution is achieved there are so > > > many unpatched privilege escalation vectors on Windows that a > > > network service has already lost the machine, so you might as > > > well make the next step as hard as possible. > > > > > > Account, password and depends now work (and are delivered to our > > > test team), looking at QPID-1423 today... > > > > > > On Thu, Apr 1, 2010 at 4:27 PM, Steve Huston > <[email protected]> > > > wrote: > > > > > > > This sounds great, Kerry. Looking forward to seeing it. > > > > > > > > -Steve > > > > > > > > > -----Original Message----- > > > > > From: Kerry Bonin [mailto:[email protected]] > > > > > Sent: Thursday, April 01, 2010 1:30 PM > > > > > To: [email protected] > > > > > Subject: Re: Access to qpidd original arg list from {platform > > > > > specific}QpiddBroker.cpp ? > > > > > > > > > > > > > > > LocalService still has access to the network, and is > generally > > > > > preferable over NetworkService - NetworkService tries > to use the > > > > > domain account privileges it is running under, whereas > > > LocalService > > > > > is treated as an anonymous network agent. A hacked > > > service running > > > > > under NetworkService will therefore have more > privileges in the > > > > > local network than one running under LocalService, so > unless you > > > > > need to interact with the domain, LocalService is > preferred for > > > > > network services. > > > > > > > > > > On the service abstraction issue, I've now been able to > > > contain all > > > > > the Windows service code to the Windows specific > > > > > QpiddBroker.cpp, and reverted all my changes to qpidd.cpp. > > > > > (Although I am adding a WinService .cpp/.h with my generic > > > > > service helper class.) So the platform abstraction > is as clean > > > > > as possible on the > > > Windows side. > > > > > The only other interaction between the service code and > > > the broker > > > > > is during shutdown, in which case I preserve the Broker * > > > and call > > > > > the > > > > > shutdown() API. > > > > > > > > > > I've added --start-type={auto|demand|disabled}, and now > > > working on > > > > > --account, --password, and --depends (register list > of dependent > > > > > services), all as per SCM conventions. Also looking at > > > QPID-1423... > > > > > > > > > > > > > > > On Thu, Apr 1, 2010 at 12:14 PM, Andrew Stitcher > > > > > <[email protected]>wrote: > > > > > > > > > > > On Thu, 2010-04-01 at 11:46 -0500, Kerry Bonin wrote: > > > > > > > There is a UAC issue on installing a service, in that if > > > > > you try and > > > > > > > use > > > > > > the > > > > > > > --install command while logged in as a user that does > > > not have > > > > > > > the > > > > > > privilege > > > > > > > to install services, it will (properly) fail. So that is > > > > > working as > > > > > > > it should - in our testing here we use that command > > > during our > > > > > > > installation process, which is running with elevated > > > > > privileges, so > > > > > > > it works at that time, as it should. > > > > > > > > > > > > > > As for normal use, I have the broker by default install > > > > > itself under > > > > > > > the LocalSystem account, which IIRC is the recommended > > > > > account for > > > > > > > services, > > > > > > and > > > > > > > this account has reduced privileges on later Windows. If > > > > > you NEED > > > > > > > to run > > > > > > it > > > > > > > with more or less privileges, you can create or use > > > an existing > > > > > > > account appropriately, and just tell the broker to use > > > > > that account > > > > > > > - you only > > > > > > need > > > > > > > to provide the credentials once, and Windows SCM manages > > > > > the token > > > > > > > generation and caching as per normal SCM rules, and > > > when you try > > > > > > installing > > > > > > > it you would obviously need sufficient rights to use that > > > > > > > account AND install a service. > > > > > > > > > > > > Doesn't it have to be the 'NETWORK SERVICE' account for > > > it to have > > > > > > access to the network? which you'd think it would need! In > > > > > more recent > > > > > > versions of windows the service accounts are split. > > > > > > > > > > > > > > > > > > > > I'm pretty sure this all meets guidelines, as I'm never > > > > > > > violating any security rules that I know of... > (and I'm a > > > > > > > hardcore > > > > > security / > > > > > > > crypto geek, 25+ years...) > > > > > > > > > > > > > > If you would like me to disable the self-installation > > > features > > > > > > > before > > > > > > patch, > > > > > > > I certainly can... > > > > > > > > > > > > No need, I was working from a faulty memory, and I can't > > > > > think of any > > > > > > good reason to exclude this functionality. I suspect the > > > > > much bigger > > > > > > issue is going to be how the Unix daemonisation and the > > > > > > Windows service code are both abstracted so that the code > > > becomes easier > > > > > > to maintain. > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > > > Apache Qpid - AMQP Messaging Implementation > > > > > > Project: http://qpid.apache.org > > > > > > Use/Interact: mailto:[email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - > > > > Apache Qpid - AMQP Messaging Implementation > > > > Project: http://qpid.apache.org > > > > Use/Interact: mailto:[email protected] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > Apache Qpid - AMQP Messaging Implementation > > Project: http://qpid.apache.org > > Use/Interact: mailto:[email protected] > > > > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
