On Wed, Dec 19, 2012 at 3:56 AM, Ullmann d.o.o. <en...@ullmann.hr> wrote:
> Hello mailing list.
>
> In the Debian Wheezy rep. is still the version 1.3.18-2.
>
> When reading this: http://ledgersmb.org/topic/security-reports
> I get a bit worried.
> Shoud I stay or should I go now ..... :D
>
> Is someone taking care of that?
I don't know if that security fix has been backported to the .deb. I hope
so. However, to explain what was actually going on here.
Jame, did this get backported there? Or should I send a fix to this user?
In LedgerSMB 1.2 and below, there was no hard enforcement of permissions
(this was documented in our manual as a shortcoming, and a behavior we
inherited from SQL-Ledger). Instead permissions were largely a matter of
hiding options in the user interface. An enterprising individual with
login access could thus obtain essentially all access to the application
with the possible exception of user management.
in 1.3 we tackled this problem by pushing most permissions enforcement to
the database. In 1.3 thus permissions are enforced strictly, usually by
the database engine. This has some advantages including consistent
enforcement across applications and the fact that this allowed us to
relatively quickly retrofit a codebase which was not designed for security
with some real security controls.
The problem occurred with the defaults table, which stores settings for the
current company. The problem is that users routinely require read
permission to the entire table and write permission to significant portions
of the table. Because this is not well controlled, some enforcement needs
to be done on the middleware end for now (this will probably change in
1.4). However, this component was omitted.
What this means is that if the security issue still affects your version,
another co-worker with login access but not administrative access could
tamper with some settings. In most cases, the worst that can happen is a
bit of embarrassment (tampering with the company name sent out on invoices,
for example), but there are two other slightly more severe consequences.
The first is that in some configurations, someone could turn off reversal
enforcement and then start deleting invoices. This might be done to cover
embezzlement or the like. Out of the box this isn't a danger because the
db permissions are inadequate to delete any transactions, but if you go
through the action of making this work and then revert to enforcing
transaction reversal, there is additional risk. Note that audit trails
can no longer be disabled in LedgerSMB 1.3 nor can they be deleted by users
with our standard permissions.
The second is that some people live in places that require that all
invoices are issued in series, with no gaps. Because someone can tamper
with the next invoice number to be issued, this can cause regulatory
headaches if you live in such a place.
I can send you a fix if you need it. It is a relatively simple and
non-intrusive change to the code. However it is relatively minor in the
sense that a disgruntled employee can probably find more effective ways of
hurting your business, and unless you put some effort into it, it can't be
used to hide embezzlement from the owners.
Best wishes,
Chris Travers
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
