[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110211163216.GA6634@mail.hallyn.com>
Date: Fri, 11 Feb 2011 16:32:16 +0000
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Serge E. Hallyn" <serge@...lyn.com>,
Gergely Nagy <algernon@...abit.hu>, david@...g.hm,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Marc Koschewski <marc@...nowledge.org>,
lkml <linux-kernel@...r.kernel.org>,
James Morris <jmorris@...ei.org>,
Nick Bowler <nbowler@...iptictech.com>
Subject: Re: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v3)
Quoting Linus Torvalds (torvalds@...ux-foundation.org):
> On Thu, Feb 10, 2011 at 6:40 AM, Serge E. Hallyn <serge@...lyn.com> wrote:
> >
> > Please apply.
>
> Hmm. So I detest the duplication and the ugly resulting code. It was
> a bit hard to follow before, now it's just nasty.
>
> Why not make this all into some nicer helper functions instead -
> something simple like the attached?
>
> UNTESTED! I'm not going to apply it unless I get acks/tested-by's.
Acked-by: Serge Hallyn <serge.hallyn@...onical.com>
Tested-by: Serge Hallyn <serge.hallyn@...onical.com>
I tested using klogctl with actions 10, 3 and 5. Without
dmesg_restrict set, an unprivileged program could get the
size and read-all, but not clear the buffer. With either
CAP_SYS_ADMIN or CAP_SYSLOG, it could do all three. With
dmesg_restrict set, the capabilities were needed for all
actions.
Worked perfectly.
thanks,
-serge
> Linus
> kernel/printk.c | 54 +++++++++++++++++++++++++++++++++++-------------------
> 1 files changed, 35 insertions(+), 19 deletions(-)
>
> diff --git a/kernel/printk.c b/kernel/printk.c
> index 2ddbdc7..f51214c 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -262,25 +262,47 @@ int dmesg_restrict = 1;
> int dmesg_restrict;
> #endif
>
> +static int syslog_action_restricted(int type)
> +{
> + if (dmesg_restrict)
> + return 1;
> + /* Unless restricted, we allow "read all" and "get buffer size" for everybody */
> + return type != SYSLOG_ACTION_READ_ALL && type != SYSLOG_ACTION_SIZE_BUFFER;
> +}
> +
> +static int check_syslog_permissions(int type, bool from_file)
> +{
> + /*
> + * If this is from /proc/kmsg and we've already opened it, then we've
> + * already the capabilities checks at open time.
> + */
> + if (from_file && type != SYSLOG_ACTION_OPEN)
> + return 0;
> +
> + if (syslog_action_restricted(type)) {
> + if (capable(CAP_SYSLOG))
> + return 0;
> + /* For historical reasons, accept CAP_SYS_ADMIN too, with a warning */
> + if (capable(CAP_SYS_ADMIN)) {
> + WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN "
> + "but no CAP_SYSLOG (deprecated).\n");
> + return 0;
> + }
> + return -EPERM;
> + }
> + return 0;
> +}
> +
> int do_syslog(int type, char __user *buf, int len, bool from_file)
> {
> unsigned i, j, limit, count;
> int do_clear = 0;
> char c;
> - int error = 0;
> + int error;
>
> - /*
> - * If this is from /proc/kmsg we only do the capabilities checks
> - * at open time.
> - */
> - if (type == SYSLOG_ACTION_OPEN || !from_file) {
> - if (dmesg_restrict && !capable(CAP_SYSLOG))
> - goto warn; /* switch to return -EPERM after 2.6.39 */
> - if ((type != SYSLOG_ACTION_READ_ALL &&
> - type != SYSLOG_ACTION_SIZE_BUFFER) &&
> - !capable(CAP_SYSLOG))
> - goto warn; /* switch to return -EPERM after 2.6.39 */
> - }
> + error = check_syslog_permissions(type, from_file);
> + if (error)
> + goto out;
>
> error = security_syslog(type);
> if (error)
> @@ -423,12 +445,6 @@ int do_syslog(int type, char __user *buf, int len, bool from_file)
> }
> out:
> return error;
> -warn:
> - /* remove after 2.6.39 */
> - if (capable(CAP_SYS_ADMIN))
> - WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN "
> - "but no CAP_SYSLOG (deprecated and denied).\n");
> - return -EPERM;
> }
>
> SYSCALL_DEFINE3(syslog, int, type, char __user *, buf, int, len)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists