[ports] finding an orphan to maintain

[Damien Fleuriot]

On 14 January 2017 at 02:32, Roland Smith <rsmith at xs4all.nl> wrote:
> On Thu, Jan 12, 2017 at 09:21:16PM +0100, Damien Fleuriot wrote:
>> On 12 January 2017 at 17:47, Roland Smith <rsmith at 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.
>
> There is another (somewhat heavyhanded) approach to restricting commands.
> You could copy binaries for allowed programs to a special directory (to be put
> in $PATH) and remove read/execute access for others from the normal `bin` directories.
>
>> 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.
>
> I thought OpenBSM was ported to Linux, but it seems to miss auditd because of
> kernel support. Pity.
>
>> >> 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.
>
> Not a good sign. And I think he has a point, seeing how lshell uses Python's
> subprocess module.
>
>> >> 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.
>
> For just one port, bringing up Poudiere is surely overkill?
>
> My workflow for modifying a port is generally as follows (using sysutils/conky
> as an example):
>
>     > mkdir scratch
>     > cd scratch/
>     > cp -Rp /usr/ports/sysutils/conky .
>     > cp -Rp /usr/ports/sysutils/conky conky.orig
>     > cd conky/
>     [Make whatever changes necessary, then run the following tests (from the
>     Porters Handbook) *as a normal user*, unless otherwise (#) indicated]
>     > make stage
>     > make check-orphans
>     > make package
>     > portlint .
>     # make install
>     # make deinstall
>     # pkg add package-filename
>     # pkg delete package-filename
>
> When all this works,
>
>     # make clean
>     > cd ..
>     > diff -ruN conky.orig/ conky/ > patch-for-conky.diff
>
> Attach the diff to a PR.
>

Well, it could be considered overkill in the case of just one package.

However, lshell's code has been entirely refactored in 0.9.17
(removing calls to os.system I think it was).
That on top of jumping 2 versions at once, sort of justify being extra cautious.

Additionally, claiming MAINTAINER'ship over the port means I may have
to submit diff files more frequently (although I remain skeptical, see
my note at the bottom regarding upstream).
Poudriere should help in running unit tests and ensuring the updated
port works for everyone, out of the box.




Furthermore, you lack context here.

We use FBSD 8 and 10 boxes at work for firewalling purposes.
These all come standard with nagios, ossec-hids, munin, bacula.
Some of them run relayd, others have nginx and/or haproxy.


I currently use a dedicated VM for the purposes of :
- rebuilding kernel + world with custom src.conf and make.conf options
(and custom kernel obviously)
- building and upgrading packages from source

The goal here is to only use that which we strictly need (which helps
WRT PCI-DSS compliance, and reduces our attack surface in case of
defects in modules or dependencies).

My kernels have no sound or PCMCIA or ISA or wifi, my worlds have no
X11 or CUPS, my ports have no NLS or IP6, for example.


I currently build said packages manually, every month or important CVE
I svnup ports, then portmaster to rebuild, and make the updated
packages available over HTTP via nginx to our other boxes.

I trust Poudriere is going to help with this process, although I think
I shall have to keep 2 separate boxes now :
- a -CURRENT box for Poudriere jails including 11.x
- and my 10-STABLE box for world and kernel.




Last but not least, this gives me an opportunity to :
- learn (new, interesting things)
- for free (weee)
- from people who know better than do I (who better ?)

I should be a fool indeed to refuse an offered hand and pass up the
opportunity ;)


>> 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.
>
> The documentation for github in bsd.sites.mk states that you can use a hash
> from a commit as a GH_TAGNAME.
>

Aye I'd looked into bsd.sites.mk and figured that out mid-week, got a
currently working port from the latest commit hash.

Sometime this weekend when I'm bored I'll log into the host from work,
get 10-STABLE and 11-STABLE jails up, run the port build and finalize
this.


I'm afraid however there may have been a loss of interest upstream,
and I certainly shan't be able to fork/maintain the original lshell
program.



Thanks for all the feedback Roland ;)