Re: [PATCH] Define CAP_SYSLOG

[Matthew Helsley <matt.helsley@gmail.com>]

On Sat, Mar 13, 2010 at 10:35 PM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> Quoting Michael Kerrisk (mtk.manpages@googlemail.com):
>> > There is one downside to this patch:  If some site or distro currently
>> > has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
>> > then it will need to be changed to run with cap_syslog+pe.  I don't
>> > know if there are such sites, or if that concern means we should take
>> > a different approach to introducing this change, or simply refuse this
>> > change.
>>
>> *If* this is a problem, would the way to address it not be to permit
>> syslog if the caller has *either* CAP_SYS_ADMIN or CAP_SYSLOG? (The
>> only weakness I see in this idea is that it fails to lighten the
>> hugely overlaoded CAP_SYS_ADMIN.)
>
> Which becomes a very big weakness because it won't allow a
> container to be started with cap_sys_admin but not cap_syslog
> in its capability bounding set.
>
> So, if it is deemed a problem, then the alternative will be to
> introduce a syslog namespace.  Container setup can then create
> a new syslog namespace, and can no longer read or clear the
> host's syslog.
>
> thanks,
> -serge

Would it make sense to warn once when CAP_SYS_ADMIN permits what
CAP_SYSLOG will be used for in the future? Something like:

-            type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYS_ADMIN))
+            type != SYSLOG_ACTION_SIZE_BUFFER) &&
!(capable(CAP_SYSLOG)||capable(CAP_SYS_ADMIN))) {
+             WARN_ONCE(capable(CAP_SYS_ADMIN) &&
!capable(CAP_SYSLOG), "CAP_SYS_ADMIN will not permit syslog
configuration in the near future. Please switch your code to
CAP_SYSLOG\n");
               return -EPERM;
+        }
       return 0;

After a period of time allowing userspace apps to transition to
CAP_SYSLOG remove the CAP_SYS_ADMIN portions. Of course this won't fix
containers for that transition period but it would avoid a sudden
change of what CAP_SYS_ADMIN allows.

> So, if it is deemed a problem, then the alternative will be to
> introduce a syslog namespace.  Container setup can then create
> a new syslog namespace, and can no longer read or clear the
> host's syslog.

Yup, this is also an option. Possibly better as it doesn't involved
changing the meaning of a overly-[ab]used capability bit and wouldn't
require a transition period.

Cheers.
    -Matt Helsley