lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061109041400.GB6602@sequoia.sous-sol.org>
Date:	Wed, 8 Nov 2006 20:14:00 -0800
From:	Chris Wright <chrisw@...s-sol.org>
To:	Sergey Vlasov <vsu@...linux.ru>
Cc:	Chris Wright <chrisw@...s-sol.org>,
	Zack Weinberg <zackw@...ix.com>, linux-kernel@...r.kernel.org,
	sds@...ho.nsa.gov, jmorris@...ei.org
Subject: Re: RFC PATCH: apply security_syslog() only to the syslog() syscall, not to /proc/kmsg

* Sergey Vlasov (vsu@...linux.ru) wrote:
> Then what would you think about another solution:
> 
>  1) When sys_syslog() is called with commands 2 (read) or 9 (get unread
>     count), additionally call security_syslog(1) to check that the
>     process has permissions to open the kernel log.  This change by
>     itself will not make any difference, because all existing
>     implementations of the security_ops->syslog hook treat the operation
>     codes 1, 2 and 9 the same way.
> 
>  2) Change cap_syslog() and dummy_syslog() to permit commands 2 and 9
>     for unprivileged users, in addition to 3 and 10 which are currently
>     permitted.  This will not really permit access through sys_syslog()
>     due to the added security_syslog(1) check, but if a process somehow
>     got access to an open file descriptor for /proc/kmsg, it would be
>     able to read from it.  Also, because selinux_syslog() is not
>     changed, under SELinux the process will still need to have
>     additional privileges even if it has /proc/kmsg open.

It's a bit clumsy in the extra caveats for sys_syslog and cap_syslog,
but does achieve what you're after.  We lose default checking on the
actual read access, but perhaps this is a fair tradeoff.  Stephen,
James do you have any issues with this for SELinux?

thanks,
-chris
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ