Re: Changing how LedgerSMB is run and it's installation is secured

Subject: Re: Changing how LedgerSMB is run and it's installation is secured

From: David G <..hidden..>

Date: Fri, 25 Mar 2016 01:42:32 +0800

Hi Chris

On 24/03/16 18:08, Chris Travers wrote:

On Thu, Mar 24, 2016 at 1:51 AM, David G <..hidden..> wrote:

Hi All,

There has been some discussion on IRC today regarding options for running LedgerSMB (httpd) and how/what System User to run as.

The long and the short of it is the following proposal.
If you have any thoughts or suggestions could you please comment before we start implementing the changes.

We believe items 1-3 NEED to happen, the remaining items SHOULD happen depending on your responses

Only ever run LedgerSMB using Starman (High-performance preforking PSGI/Plack web server)

Only ever bind Starman to localhost

Always reverse proxy Starman port with either NGINX (preferred) or Apache

One concern I have is that I am not entirely sure that we can effectively test well in this sort of environment. We've had bugs in this corner, so I think in terms of a roadmap forward, it would be good to keep this experimental for a little bit.

At the moment running under Apache prevents print to pdf/screen (it fails with errors), while running under starman works
So your argument goes both ways.
In fact at the moment the Starman + Nginx solution is better tested than Apache as that is the configuration we are using on travis.ci for running our premerge tests.
NOTE:
    For the record this is not quite accurate, on travis we actually use Plack and Nginx. but Starman is essentially a wrapper around plack.
    The reason We are directly using Plack on travis is to overcome an issue with getting code coverage measurements .
    (It's a bug in Devel::Cover which we use to get coverage information)

At installation create a system user "ledgersmb"

At installation create a system group "ledgersmb-admin"

all LedgerSMB files should be installed in a single versioned directory (eg: /usr/share/ledgersmb-1.4.26 or /opt/ledgersmb-1.4.26)

the install directory and contents should be owned by user ledgersmb and group ledgersmb-admin

the install directory and contents should have the following permissions
For Executable files (s--r-xrw---- | 4560)

r - x for owner

r w - for group

- - - for other

For Non Executable files (r--rw---- | 460)

r - - for owner

r w - for group

- - - for other

For Directories (-s-r-xrw---- |2560)

r - x for owner

r w - for group

- - - for other

The temp dir configured in ledgersmb.conf will need to be owned by user ledgersmb and group ledgersmb-admin

The temp dir would need these permissions (sstrwxrwx--- | 7777)

- - s for flags

r w x for owner

r w x for group

- - - for other

Any system users that need to be able to modify files in the LedgerSMB dir's would need to have ledgersmb-admin added to their groups.

Information on the permissions can be found in the following man pages and links

CHMOD(1)

CHMOD(2)

UNLINK(2)

how-do-directory-permissions-in-linux-work Look at Baldrick's answer it is the best summary

Running LedgerSMB using Starman and a reverse caching proxy like nginx has significant performance benefits due to both the way Starman preforks and handles Perl assets, and the static asset caching offered by the proxy.
There is an additional benefit to running via Starman, it is less likely that an error in a latex template (for example) will cause a hard failure.
This has recently been shown to be an issue with the current debian package for 1.4.25 available from our repository http://apt.ledgersmb.org

Running as a specific system user improves security, and assists with running multiple instances on the same system.
The restricted permissions take this a step further to make it harder for things to be broken or attacked by other processes on the system.

Keeping everything from the LedgerSMB tree in a single folder instead of splitting amoung multiple system dir locations is necessary for running multiple instances on a system, especially if there will be more than one version of the code.
I am certain there are ways to work around that, but simplicity is often the best solution.
Things like the docs dir can have a symlink /usr/share/doc/ledgersmb-1.4.25 that point to the real dir
The same goes for manpages if we want to.
NOTE: for an official debian package (in the debian.org archives) we may have to split things up to comply with their policy, but there is precedent not to.
Also as debian doesn't allow version updates to packages for the life of a release Official Packages for LedgerSMB are of minimal benefit.
We are better to point people at our own repository.

Regards
David G

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

--

Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140