Date: Thu, 12 Jan 2017 21:21:16 +0100 From: Damien Fleuriot <ml@my.gd> To: Damien Fleuriot <ml@my.gd>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: [ports] finding an orphan to maintain Message-ID: <CAE63ME4Eos_RdEA_vnmDS7XRAeoyPm3uiqbC=0To3j93kd7%2B0Q@mail.gmail.com> In-Reply-To: <20170112164708.GA73939@slackbox.erewhon.home> References: <CAE63ME592BgZdTdOHr3eM-=3Vf5WZfOQ1gp4Vuqm9uM5Gbg9HQ@mail.gmail.com> <20170111110634.GB53285@slackbox.erewhon.home> <CAE63ME63yh_PBQH9SaivM3C%2B-XKG0XE=XYFBNUFAafMc-3s6uw@mail.gmail.com> <20170112164708.GA73939@slackbox.erewhon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 January 2017 at 17:47, Roland Smith <rsmith@xs4all.nl> wrote: > On Wed, Jan 11, 2017 at 12:53:02PM +0100, Damien Fleuriot wrote: >> Thanks for the additional input Roland. >> >> I currently have my eye on shells/lshell, which we use here on >> 10-STABLE for PCI-DSS compliance (restricting and logging commands). > > In this case you might want to look at auditing; > https://www.freebsd.org/doc/handbook/audit.html > > While the handbook explains how it works, I haven't really found good examples > of its use. > I thank you for the input and have indeed already looked at auditd. While it does provide very good logging, it only answers one of the prerequisites, logging, not actual command restriction. We do have another constraint which is that the software be portable to linux as well, so as to not maintain 2 different sets of logging/restriction stacks. >> It so happens the current (0.9.16_2) version on FreeBSD suffers from a >> nasty case of shell escape : >> https://github.com/ghantoos/lshell/issues/151 >> root:~$ echo () sh && echo >> # >> ^-- uh oh... > > Oops. > > Looking at the discussion of the issue, I get the impression that there are > some fundamental problems with the way lshell parses and executes commands. > Aye, bug reporter seems quite adamant that, quote, the software is entirely broken. >> I cannot seem to reproduce when using the latest master branch, and am >> seeking confirmation in the bug thread that I'm actually trying to >> reproduce correctly. >> >> If it should transpire that the problem is indeed fixed in the master, >> I shall try and update the port to the latest version. > > The port now uses SourceForge, which is getting a bad reputation these days > for adding crap to binary installers. This is probably not an issue with > tarballs, but it makes me wonder if they are still trustworthy. You might > want to consider switching to github. If you do, read > /usr/ports/Mk/bsd.sites.mk on how to properly do that in the port Makefile. > When (if) I manage to get Poudriere up and running (it's currently bitching about missing /usr/local/share/poudriere/jail.sh), I shall be able to submit run tests for a patched version of shells/lshell. The aim is to bring it up to upstream from github at version 0.9.18. Sadly lot of vulns were patched since 0.9.18 and there is no further release tag. I've asked for one today, wait and see. I shall take a look at bsd.sites.mk, I've currently put the actual URL in MASTER_SITES, but there may be a more elegant way such as using the GH macro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE63ME4Eos_RdEA_vnmDS7XRAeoyPm3uiqbC=0To3j93kd7%2B0Q>