From: "Serge E. Hallyn" <serue@us.ibm.com> To: Matthew Helsley <matt.helsley@gmail.com> Cc: mtk.manpages@gmail.com, James Morris <jmorris@namei.org>, lkml <linux-kernel@vger.kernel.org>, SELinux <selinux@tycho.nsa.gov>, linux-security-module@vger.kernel.org, Stephen Smalley <sds@epoch.ncsc.mil>, Kees Cook <kees.cook@canonical.com>, Andrew Morgan <morgan@kernel.org>, "Christopher J. PeBenito" <cpebenito@tresys.com>, Eric Paris <eparis@parisplace.org> Subject: Re: [PATCH] Define CAP_SYSLOG Date: Sun, 14 Mar 2010 23:24:31 -0500 [thread overview] Message-ID: <20100315042431.GA7550@us.ibm.com> (raw) In-Reply-To: <6a12d2f31003141816k5c637891s7e85231fc891e4e@mail.gmail.com> Quoting 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; Good idea - though I'd prefer to WARN_ONCE and then deny :) If we log and allow, the log msg will be ignored. > 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. Still I can definately see a case where you want the container to be in the host's syslog for simplicity, but not be able to clear it. -serge
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serue@us.ibm.com> To: Matthew Helsley <matt.helsley@gmail.com> Cc: mtk.manpages@gmail.com, James Morris <jmorris@namei.org>, lkml <linux-kernel@vger.kernel.org>, SELinux <selinux@tycho.nsa.gov>, linux-security-module@vger.kernel.org, Stephen Smalley <sds@epoch.ncsc.mil>, Kees Cook <kees.cook@canonical.com>, Andrew Morgan <morgan@kernel.org>, "Christopher J. PeBenito" <cpebenito@tresys.com>, Eric Paris <eparis@parisplace.org> Subject: Re: [PATCH] Define CAP_SYSLOG Date: Sun, 14 Mar 2010 23:24:31 -0500 [thread overview] Message-ID: <20100315042431.GA7550@us.ibm.com> (raw) In-Reply-To: <6a12d2f31003141816k5c637891s7e85231fc891e4e@mail.gmail.com> Quoting 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; Good idea - though I'd prefer to WARN_ONCE and then deny :) If we log and allow, the log msg will be ignored. > 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. Still I can definately see a case where you want the container to be in the host's syslog for simplicity, but not be able to clear it. -serge -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2010-03-15 4:24 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-03-12 20:55 [PATCH] Define CAP_SYSLOG Serge E. Hallyn 2010-03-12 20:55 ` Serge E. Hallyn 2010-03-12 20:58 ` [refpolicy] [PATCH refpolicy] add capability2:syslog perm Serge E. Hallyn 2010-03-14 5:18 ` [PATCH] Define CAP_SYSLOG Michael Kerrisk 2010-03-14 5:35 ` Serge E. Hallyn 2010-03-14 5:35 ` Serge E. Hallyn 2010-03-15 1:16 ` Matthew Helsley 2010-03-15 4:24 ` Serge E. Hallyn [this message] 2010-03-15 4:24 ` Serge E. Hallyn 2010-10-31 22:36 ` Console Login and SSH Login Security Contexts Hasan Rezaul-CHR010 2010-11-01 15:59 ` Christopher J. PeBenito 2010-11-01 21:11 ` Hasan Rezaul-CHR010 2010-11-02 7:48 ` HarryCiao 2010-11-02 13:36 ` Christopher J. PeBenito 2010-11-02 18:12 ` Hasan Rezaul-CHR010 2010-11-01 5:27 ` Format of file_contexts file Hasan Rezaul-CHR010 2010-11-01 16:02 ` Christopher J. PeBenito
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100315042431.GA7550@us.ibm.com \ --to=serue@us.ibm.com \ --cc=cpebenito@tresys.com \ --cc=eparis@parisplace.org \ --cc=jmorris@namei.org \ --cc=kees.cook@canonical.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=matt.helsley@gmail.com \ --cc=morgan@kernel.org \ --cc=mtk.manpages@gmail.com \ --cc=sds@epoch.ncsc.mil \ --cc=selinux@tycho.nsa.gov \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.