[syslog-ng] Bug report: syslog-ng requests too many capabilities

[Nagy, Gábor]

Hi Dominik!

I don't know if you got what I replied on IRC, but basically I was
wrong there as I only focused on init time capability setting and not
on the runtime errors. Sorry. :)
I can only agree with @algernon's statement I have found examples of
capability mishandling too (although in some points we do check what
kind of capability is needed, in affile/file-opener).

Reflecting on your topics:
>
> In my opinion, there are 2 bugs in syslog-ng:
> * if I tell a daemon to run as unprivileged user I do not expect it to
>   write files as user root. What syslog-ng is doing basically is faking
>   being an unprivileged user, while retaining capabilities which are
>   equivalent to full root permissions.
>   Syslog-ng should imho either run as root, with capabilities;
>   OR as unprivileged user without capabilities (except those
>   explicitly given in --caps)
> * syslog-ng drops to the capabilities it gets told in --caps,
>   but later g_process_cap_modify() ignores what was specified.

1. creating files as root:
I can confirm that files are created with root even if --user or
--group is used.
Although we call setuid() in gprocess at startup, during file opening
we use file permissions explicitly from the global config, which
defaults to root.
I think this is a bug too and we should solve it.

What you can do as **workaround** is to set file() options: owner()
group() without a value in the configuration.
We documented this too:
https://syslog-ng.com/documents/html/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/reference-destination-file.html


2. syslog-ng drops capabilities
Syslog-ng sets capabilities given with options --caps at startup.
I think the issue here is that some capabilities are hard-wired into
syslog-ng (as you have found calls of g_process_cap_modify()).

BR,
Gabor


On Wed, Apr 18, 2018 at 3:49 PM, Scheidler, Balázs
<balazs.scheidler at balabit.com> wrote:
> Also, you can tell it not to manage capabilities with the --no-caps command
> line option.
>
> --
> Bazsi
>
> On Wed, Apr 18, 2018 at 3:18 PM, Gergely Nagy <algernon at balabit.com> wrote:
>>
>> Hi!
>>
>> >>>>> "Russenberger" == Russenberger Dominik
>> >>>>> <dominik.russenberger at terreactive.ch> writes:
>>
>>     Russenberger> Hi List,
>>     Russenberger> I recently noticed something very strange: although I
>> run syslog-ng as
>>     Russenberger> an unprivileged user (with -u log -g log), newly created
>> logfiles were
>>     Russenberger> owned by root. syslog-ng shows up running as user log in
>> ps, as expected.
>>
>>     Russenberger> In my opinion, there are 2 bugs in syslog-ng:
>>     Russenberger> * if I tell a daemon to run as unprivileged user I do
>> not expect it to
>>     Russenberger> write files as user root. What syslog-ng is doing
>> basically is faking
>>     Russenberger> being an unprivileged user, while retaining capabilities
>> which are
>>     Russenberger> equivalent to full root permissions.
>>     Russenberger> Syslog-ng should imho either run as root, with
>> capabilities;
>>     Russenberger> OR as unprivileged user without capabilities (except
>> those
>>     Russenberger> explicitly given in --caps)
>>     Russenberger> * syslog-ng drops to the capabilities it gets told in
>> --caps,
>>     Russenberger> but later g_process_cap_modify() ignores what was
>> specified.
>>
>> While I agree about your conclusion that syslog-ng should not use more
>> capabilities than it is told - or what it needs to -, I'd like to shed
>> some light on why it tries to raise its capabilities despite you telling
>> it to run with less.
>>
>> The reason is actually pretty simple: syslog-ng supports the `owner()`
>> and `group()` options for some destinations, so that it can create
>> output files as a different user than syslog-ng is running under. For
>> this reason, whenever creating such files, it first tries to raise its
>> capabilities, just to make sure it can create them. We currently do not
>> keep track of whether this is required or not, we try to raise anyway.
>>
>> We should probably change that, and only raise capabilities if we really
>> need to. This should solve the issue you are seeing.
>>
>> --
>> |8]
>>
>> ______________________________________________________________________________
>> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> Documentation:
>> http://www.balabit.com/support/documentation/?product=syslog-ng
>> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>>
>
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>