You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Steve Huston <sh...@riverace.com> on 2010/03/29 23:15:46 UTC
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Looks nice, Kerry!
I don't have many answers for you at this point, but one note...
> Use of event log
There is already a logging option to put stuff in the windows event log.
> As a side note, if anyone has any other suggestions related
> to this or other service features, please let me know and
> I'll see if I can add it.
The installer build is going to be checked in sometime soon. This builds
a WiX-based installer; it may be nice to add the ability to install the
broker as a service during the install.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Kerry Bonin <ke...@gmail.com>.
Hello Steve! I'll take a look at fixing QPID-1423 next, hadn't seen it
before...
Kerry
On Tue, Mar 30, 2010 at 11:52 AM, Steve Huston <sh...@riverace.com> wrote:
> Hi Kerry,
>
> > Hello, and thanks for the comments!
>
> You're welcome - thanks for working on a very useful addition!
>
> > On the event log, I hadn't seen that option yet, I'll look
> > for it and not add another one...
>
> Great - also please note QPID-1423 if you wish to make some improvement
> there:
> https://issues.apache.org/jira/browse/QPID-1423
>
> Thanks,
> -Steve
>
> > On Mon, Mar 29, 2010 at 4:15 PM, Steve Huston
> > <sh...@riverace.com> wrote:
> >
> > > Looks nice, Kerry!
> > >
> > > I don't have many answers for you at this point, but one note...
> > >
> > > > Use of event log
> > >
> > > There is already a logging option to put stuff in the windows event
> > > log.
> > >
> > > > As a side note, if anyone has any other suggestions
> > related to this
> > > > or other service features, please let me know and I'll
> > see if I can
> > > > add it.
> > >
> > > The installer build is going to be checked in sometime soon. This
> > > builds a WiX-based installer; it may be nice to add the ability to
> > > install the broker as a service during the install.
> > >
> > > -Steve
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > Apache Qpid - AMQP Messaging Implementation
> > > Project: http://qpid.apache.org
> > > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Posted by Steve Huston <sh...@riverace.com>.
> 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
> <sh...@riverace.com> wrote:
>
> > Thanks for checking into best practices here, Kerry!
> >
> > -Steve
> >
> > > -----Original Message-----
> > > From: Kerry Bonin [mailto:kerrybonin@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
> <sh...@riverace.com>
> > > wrote:
> > >
> > > > This sounds great, Kerry. Looking forward to seeing it.
> > > >
> > > > -Steve
> > > >
> > > > > -----Original Message-----
> > > > > From: Kerry Bonin [mailto:kerrybonin@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
> > > > > <as...@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-subscribe@qpid.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> --------------------------------------------------------------------
> > > -
> > > > Apache Qpid - AMQP Messaging Implementation
> > > > Project: http://qpid.apache.org
> > > > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Kerry Bonin <ke...@gmail.com>.
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 <sh...@riverace.com> wrote:
> Thanks for checking into best practices here, Kerry!
>
> -Steve
>
> > -----Original Message-----
> > From: Kerry Bonin [mailto:kerrybonin@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
> > <sh...@riverace.com> wrote:
> >
> > > This sounds great, Kerry. Looking forward to seeing it.
> > >
> > > -Steve
> > >
> > > > -----Original Message-----
> > > > From: Kerry Bonin [mailto:kerrybonin@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
> > > > <as...@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-subscribe@qpid.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > Apache Qpid - AMQP Messaging Implementation
> > > Project: http://qpid.apache.org
> > > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Posted by Steve Huston <sh...@riverace.com>.
Thanks for checking into best practices here, Kerry!
-Steve
> -----Original Message-----
> From: Kerry Bonin [mailto:kerrybonin@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
> <sh...@riverace.com> wrote:
>
> > This sounds great, Kerry. Looking forward to seeing it.
> >
> > -Steve
> >
> > > -----Original Message-----
> > > From: Kerry Bonin [mailto:kerrybonin@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
> > > <as...@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-subscribe@qpid.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Kerry Bonin <ke...@gmail.com>.
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 <sh...@riverace.com> wrote:
> This sounds great, Kerry. Looking forward to seeing it.
>
> -Steve
>
> > -----Original Message-----
> > From: Kerry Bonin [mailto:kerrybonin@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
> > <as...@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-subscribe@qpid.apache.org
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Posted by Steve Huston <sh...@riverace.com>.
This sounds great, Kerry. Looking forward to seeing it.
-Steve
> -----Original Message-----
> From: Kerry Bonin [mailto:kerrybonin@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
> <as...@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-subscribe@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Kerry Bonin <ke...@gmail.com>.
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 <as...@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-subscribe@qpid.apache.org
>
>
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Andrew Stitcher <as...@redhat.com>.
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-subscribe@qpid.apache.org
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Kerry Bonin <ke...@gmail.com>.
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.
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...
Kerry
On Thu, Apr 1, 2010 at 9:33 AM, Andrew Stitcher <as...@redhat.com>wrote:
> On Tue, 2010-03-30 at 11:21 -0500, Kerry Bonin wrote:
> > Hello, and thanks for the comments!
> >
> > First, thank you Andrew for GetCommandLine() - 20 something years on
> > Windows, and I don't remember seeing that one before, certainly made this
> > simpler.
> >
> > On the subject of the command line in general for a service - I agree
> that
> > under most normal use a config file should be used, I just wanted to make
> > sure the command line was usable...
> >
> > On the security of self-installing services - if the service is doing
> much
> > more than installing itself, especially if it contains baked in
> credentials,
> > ect., that would be a very bad thing. What I've done is essentially the
> > equivalent of sc create|start|stop|delete wrap as a convenience function,
> > nothing more, and the calls execute with the same privilege level a user
> has
> > available to them at the command line.
>
> ISTR that the issue is related to UAC, but I admit I can't quite see
> what the issue could be.
>
> One security related issue I'd suggest is that if running qpid as a
> service then we should run as an unprivileged user though with network
> access. qpidd only shuffles bits around a network so doesn't seem to
> need elevated privileges.
>
> I'm not sure how this fits exactly, but I assume that you'd need to
> create a new user account on installation and run the service using it.
> This would obviously require admin privileges.
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Andrew Stitcher <as...@redhat.com>.
On Tue, 2010-03-30 at 11:21 -0500, Kerry Bonin wrote:
> Hello, and thanks for the comments!
>
> First, thank you Andrew for GetCommandLine() - 20 something years on
> Windows, and I don't remember seeing that one before, certainly made this
> simpler.
>
> On the subject of the command line in general for a service - I agree that
> under most normal use a config file should be used, I just wanted to make
> sure the command line was usable...
>
> On the security of self-installing services - if the service is doing much
> more than installing itself, especially if it contains baked in credentials,
> ect., that would be a very bad thing. What I've done is essentially the
> equivalent of sc create|start|stop|delete wrap as a convenience function,
> nothing more, and the calls execute with the same privilege level a user has
> available to them at the command line.
ISTR that the issue is related to UAC, but I admit I can't quite see
what the issue could be.
One security related issue I'd suggest is that if running qpid as a
service then we should run as an unprivileged user though with network
access. qpidd only shuffles bits around a network so doesn't seem to
need elevated privileges.
I'm not sure how this fits exactly, but I assume that you'd need to
create a new user account on installation and run the service using it.
This would obviously require admin privileges.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Posted by Steve Huston <sh...@riverace.com>.
Hi Kerry,
> Hello, and thanks for the comments!
You're welcome - thanks for working on a very useful addition!
> On the event log, I hadn't seen that option yet, I'll look
> for it and not add another one...
Great - also please note QPID-1423 if you wish to make some improvement
there:
https://issues.apache.org/jira/browse/QPID-1423
Thanks,
-Steve
> On Mon, Mar 29, 2010 at 4:15 PM, Steve Huston
> <sh...@riverace.com> wrote:
>
> > Looks nice, Kerry!
> >
> > I don't have many answers for you at this point, but one note...
> >
> > > Use of event log
> >
> > There is already a logging option to put stuff in the windows event
> > log.
> >
> > > As a side note, if anyone has any other suggestions
> related to this
> > > or other service features, please let me know and I'll
> see if I can
> > > add it.
> >
> > The installer build is going to be checked in sometime soon. This
> > builds a WiX-based installer; it may be nice to add the ability to
> > install the broker as a service during the install.
> >
> > -Steve
> >
> >
> >
> ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Kerry Bonin <ke...@gmail.com>.
Hello, and thanks for the comments!
First, thank you Andrew for GetCommandLine() - 20 something years on
Windows, and I don't remember seeing that one before, certainly made this
simpler.
On the subject of the command line in general for a service - I agree that
under most normal use a config file should be used, I just wanted to make
sure the command line was usable...
On the security of self-installing services - if the service is doing much
more than installing itself, especially if it contains baked in credentials,
ect., that would be a very bad thing. What I've done is essentially the
equivalent of sc create|start|stop|delete wrap as a convenience function,
nothing more, and the calls execute with the same privilege level a user has
available to them at the command line.
On the account / password arguments for the service - these are NOT retained
by the service in any way - they are merely passed to the SCM as part of
service creation in the exact same way the sc command lets you specify the
obj and password arguments - they are then used by the SCM to create a
security token which is placed in the registry along with the service data,
and used when the service is started.
On the event log, I hadn't seen that option yet, I'll look for it and not
add another one...
Kerry
On Mon, Mar 29, 2010 at 4:15 PM, Steve Huston <sh...@riverace.com> wrote:
> Looks nice, Kerry!
>
> I don't have many answers for you at this point, but one note...
>
> > Use of event log
>
> There is already a logging option to put stuff in the windows event log.
>
> > As a side note, if anyone has any other suggestions related
> > to this or other service features, please let me know and
> > I'll see if I can add it.
>
> The installer build is going to be checked in sometime soon. This builds
> a WiX-based installer; it may be nice to add the ability to install the
> broker as a service during the install.
>
> -Steve
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>