Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Jul 2017 17:05:56 -0400
From: "Perry E. Metzger" <perry@...rmont.com>
To: Ben Tasker <ben@...tasker.co.uk>
Cc: oss-security@...ts.openwall.com, Daniel SkowroĊ„ski
 <daniel@...nf.net>
Subject: Re: systemd fails to parse user that should run
 service

On Wed, 5 Jul 2017 13:28:43 +0100 Ben Tasker <ben@...tasker.co.uk>
wrote:
> You'd really hope it'd be consistent. If they want to enforce a
> policy that user names cannot start with a digit (which as
> Poettering notes, many distro's do) that's fine, but the resulting
> behaviour should be safe, well defined and expected. I wouldn't say
> running the service as root falls under that definition, personally.

1) However, not all distributions enforce such a rule, and a has been
noted, such a rule doesn't exist in POSIX. Indeed, a quick check on a
PDP-11 simulator demonstrates that Unix at least back to v7 handled
such names without trouble.

2) The lack of fail safety is disturbing. It is probably important for
systems code like this to always fail safely, rather than unsafely.

> Honestly, I think upstream have done an *awful *job of handling it
> so far (and it's far from the only example of Poettering taking the
> not-a-bug approach questionably).

I've long since come to the conclusion that systemd is not safe to run
on a security critical machine. The developers are simply too lax
about safety.

If you're going to write a piece of systems code that has to run on
essentially every Linux box on earth and which runs much of the time
as root, extreme care has to be taken. You need to program defensively.

Instead, what we seem to have is a set of highly interdependent
shotgun parsers written without much regard to the rules people have
developed (of necessity) for writing code that must run with high
privileges. In other words, the code is _not_ written defensively.

(For those not familiar with the term "shotgun parser", which the
LangSec community introduced, do learn about it. It's a useful
concept.)

> FWIW, I'd be inclined to agree that it needs a CVE so that
> downstream distro's can at least refer to it, and decide how (and
> if) they want to address it.

+1

I don't care much if the developers deny that this is a problem. It is
a problem.

Perry
-- 
Perry E. Metzger		perry@...rmont.com

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.