One question - should I create a new jira, or use an existing, to submit the patch ?
On Fri, Apr 2, 2010 at 11:34 AM, Steve Huston <shus...@riverace.com> wrote: > Thanks for checking into best practices here, Kerry! > > -Steve > > > -----Original Message----- > > From: Kerry Bonin [mailto:kerrybo...@gmail.com] > > Sent: Friday, April 02, 2010 11:33 AM > > To: dev@qpid.apache.org > > 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 > > <shus...@riverace.com> wrote: > > > > > This sounds great, Kerry. Looking forward to seeing it. > > > > > > -Steve > > > > > > > -----Original Message----- > > > > From: Kerry Bonin [mailto:kerrybo...@gmail.com] > > > > Sent: Thursday, April 01, 2010 1:30 PM > > > > To: dev@qpid.apache.org > > > > 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 > > > > <astitc...@redhat.com>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:dev-subscr...@qpid.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > Apache Qpid - AMQP Messaging Implementation > > > Project: http://qpid.apache.org > > > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > > > > > > > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
