systemd requires HTTP server and serves QR codes
 

Am I the only one who raised his eyebrow when today's systemd update to
systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs?

-- Petr

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

> From: Petr Pisar <ppisar@redhat.com>

> Am I the only one who raised his eyebrow when
today's systemd update to

> systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs?



I suspect it has to do with this feature:



http://www.h-online.com/open/news/item/Systemd-to-secure-system-log-information-against-attacks-1671165.html



--

John Florian

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

On Mon, 08.10.12 14:50, Petr Pisar (ppisar@redhat.com) wrote:

> Am I the only one who raised his eyebrow when today's systemd update to
> systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs?

The live-syncing logging logic that is available in 184 as a preview is
based on JSON and HTTP (in order to build as much on existing standards
as possible, and get best integration with other systems). In order to
keep the footprint low we decided to use an existing embeddable minimal
HTTP engine for that, rather than writing our own. Correspondingly the
microhttpd library is only pulled in by the journal gateway daemon,
which is responsible for the HTTP iface to the journal. We thought about
splitting this off into an individual package (and it would be really
easy to still do that), but as the code of libmicrohttpd is minimal, and
it doesn't pull in any deps beyond what is already in the minimal
installation set we didn't bother so far. Note that the code is not
enabled unless people do "systemctl enable
systemd-journal-gatewayd.service".

The QR code stuff is for showing a scannable QR code for the FSS sealing
key. It's a gimmick. In order to minimize footprint we actually made
sure that the qrencode pacakge got split up in order not to pull in any
additional packages into the basic set. It too is a really minimal dep,
pulling nothing else in that wasn't in the minimal installation set
already. Here too, was the option to implement our own thing, our own QR
encoding code or just use the existing solution whose code is quite OK,
whose deps are minimal, and which is quite well tested already. With the
qrencode package split-up we were quite happy with having a dep on it.

Hopes this makes sense,

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

On Mon, Oct 08, 2012 at 02:50:23PM +0000, Petr Pisar wrote:
> Am I the only one who raised his eyebrow when today's systemd update to
> systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs?

In terms of _size_, there's not much concern, as these are both very small
libraries.

In terms of *policy*, it does seem like this may be headed towards the path
of an eventual realization that putting all this functionality into one
monolithic package has some drawbacks.

I believe that both of these are for the journal (ie, logging). If the
systemd-journal-gatewayd service is running, one can connect via http on
localhost and get a file in /var/log/messages-like format or JSON.

This is kind of nifty, but raises a few questions. Traditionally, "messages"
data is world-readable, but for a few years we've been shipping it readable
only by root. What policy do we want for this, and what's the mechanism for
enforcing it?




--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm@fedoraproject.org>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

On Mon, Oct 08, 2012 at 11:49:47AM -0400, Matthew Miller wrote:
> In terms of *policy*, it does seem like this may be headed towards the path
> of an eventual realization that putting all this functionality into one
> monolithic package has some drawbacks.

(A concern Lennart addresses in his message parallel to this one. As long as
it remains easy to split up if that later becomes important, I'm not too
concerned.)

--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm@fedoraproject.org>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

On Mon, 08.10.12 11:49, Matthew Miller (mattdm@fedoraproject.org) wrote:

> On Mon, Oct 08, 2012 at 02:50:23PM +0000, Petr Pisar wrote:
> > Am I the only one who raised his eyebrow when today's systemd update to
> > systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs?
>
> In terms of _size_, there's not much concern, as these are both very small
> libraries.
>
> In terms of *policy*, it does seem like this may be headed towards the path
> of an eventual realization that putting all this functionality into one
> monolithic package has some drawbacks.

Well, sure it has drawbacks. But it also has benefits. Right now I
believe the benefits outweigh the drawbacks, and splitting this off one
day is easy. Hence I'd like to leave it as it is right now in F18.

> I believe that both of these are for the journal (ie, logging). If the
> systemd-journal-gatewayd service is running, one can connect via http on
> localhost and get a file in /var/log/messages-like format or JSON.

Correct. Note that this is not accessible at all, by default, and mostly
a preview for now. Later on we will add http digest auth and proper TLS
support (including client certs) if people want to control
access. (thankfully, libmicrohttpd already implements auth+tls, so this
is easy for us to provide).

> This is kind of nifty, but raises a few questions. Traditionally, "messages"
> data is world-readable, but for a few years we've been shipping it readable
> only by root. What policy do we want for this, and what's the mechanism for
> enforcing it?

Well, the idea is certainly here to provide read access to all
messages, if this is enabled. The default will always be to grant no
access at all via HTTP.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

On Mon, Oct 8, 2012 at 5:31 PM, Lennart Poettering <mzerqung@0pointer.de> wrote:
> On Mon, 08.10.12 14:50, Petr Pisar (ppisar@redhat.com) wrote:
>
>> Am I the only one who raised his eyebrow when today's systemd update to
>> systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs?
>
> The live-syncing logging logic that is available in 184 as a preview is
> based on JSON and HTTP (in order to build as much on existing standards
> as possible, and get best integration with other systems). In order to
> keep the footprint low we decided to use an existing embeddable minimal
> HTTP engine for that, rather than writing our own. Correspondingly the
> microhttpd library is only pulled in by the journal gateway daemon,
> which is responsible for the HTTP iface to the journal. We thought about
> splitting this off into an individual package (and it would be really
> easy to still do that), but as the code of libmicrohttpd is minimal, and
> it doesn't pull in any deps beyond what is already in the minimal
> installation set we didn't bother so far.

We support a "minimal installation" target
(https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this
really doesn't seem like something that should be included, for the
same reason we don't ship a disabled-by-default ident or httpd in the
minimal installation.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

On Mon, Oct 08, 2012 at 07:37:42PM +0200, Miloslav Trmač wrote:
> We support a "minimal installation" target
> (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this
> really doesn't seem like something that should be included, for the
> same reason we don't ship a disabled-by-default ident or httpd in the
> minimal installation.

I'm for a minimal installation. Let's be clear: what's the reason?


--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm@fedoraproject.org>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

On Mon, Oct 8, 2012 at 7:59 PM, Matthew Miller <mattdm@fedoraproject.org> wrote:
> On Mon, Oct 08, 2012 at 07:37:42PM +0200, Miloslav Trmač wrote:
>> We support a "minimal installation" target
>> (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this
>> really doesn't seem like something that should be included, for the
>> same reason we don't ship a disabled-by-default ident or httpd in the
>> minimal installation.
>
> I'm for a minimal installation. Let's be clear: what's the reason?

1) Ability to review - it much easier to verify security/sanity of
files that are not there at all than of files that are present but
supposedly unused.
2) Risk of enabling the service by mistake (which, given that
journal-gatewayd will happily serve private log data to the whole
internet AFAICS, is has a pretty bad impact in this particular case).
3) Overhead/downtime associated with upgrades of unused components
(which wouldn't apply for a systemd subpackage here, but would apply
to libmicrohttpd).
4) Disk space
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd requires HTTP server and serves QR codes
 

On Mon, Oct 8, 2012 at 7:39 PM, Miloslav Trmač <mitr@volny.cz> wrote:
> On Mon, Oct 8, 2012 at 7:59 PM, Matthew Miller <mattdm@fedoraproject.org> wrote:
>> On Mon, Oct 08, 2012 at 07:37:42PM +0200, Miloslav Trmač wrote:
>>> We support a "minimal installation" target
>>> (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this
>>> really doesn't seem like something that should be included, for the
>>> same reason we don't ship a disabled-by-default ident or httpd in the
>>> minimal installation.
>>
>> I'm for a minimal installation. Let's be clear: what's the reason?
>
> 1) Ability to review - it much easier to verify security/sanity of
> files that are not there at all than of files that are present but
> supposedly unused.
> 2) Risk of enabling the service by mistake (which, given that
> journal-gatewayd will happily serve private log data to the whole
> internet AFAICS, is has a pretty bad impact in this particular case).
> 3) Overhead/downtime associated with upgrades of unused components
> (which wouldn't apply for a systemd subpackage here, but would apply
> to libmicrohttpd).
> 4) Disk space

And if it's only listening on localhost by default there's not much
point of it running on a server where there's no easy means of doing
so.

I would like to see it split into a sub package even if the subpackage
is installed by default. I think for people like this there should be
the ability to easily completely opt out (ie remove it) to completely
remove any option of compromise if they wish to do so. There's a lot
of platforms and auditors that wouldn't want this installed at all
(whether it be Fedora or RHEL) due to security risks whether it be a
valid opinion or not (ever had to deal with PCI-DSS auditors?).

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel