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]
Date:	Wed, 24 Oct 2007 18:50:42 -0700 (PDT)
From:	david@...g.hm
To:	"Serge E. Hallyn" <serue@...ibm.com>
cc:	"David P. Quigley" <dpquigl@...ho.nsa.gov>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Simon Arlott <simon@...e.lp0.eu>,
	Adrian Bunk <bunk@...nel.org>,
	Chris Wright <chrisw@...s-sol.org>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andreas Gruenbacher <agruen@...e.de>,
	Thomas Fricaccia <thomas_fricacci@...oo.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	James Morris <jmorris@...ei.org>,
	Crispin Cowan <crispin@...spincowan.com>,
	Giacomo Catenazzi <cate@...ian.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to	static
 interface)

On Wed, 24 Oct 2007, Serge E. Hallyn wrote:

> The scariest thing to consider is programs which don't appropriately
> handle failure.  So I don't know, maybe the system runs a remote logger
> to which the multiadm policy gives some extra privs, but now the portac
> module prevents it from sending its data.  And maybe, since the authors
> never saw this failure as possible, the program happens to dump
> sensitive data in a public readable place.  I *could* be more vague but
> it'd be tough :)  But you get the idea.
>
> Or, a better example, a privileged program reads some sensitive data -
> as allowed by multiadm, writes it to a file, but apparmor prevented it
> from chowning the file to the right user before writing, the program
> kept writing anyway, and now the calling user hallyn, rather than the
> privileged user sensitive_log_t, owns the file.
>
> I ran into examples of this with the stacker module.  For instance
> suddenly the capability module had to be changed so that it would allow
> selinux xattrs to be written - leaving that arbitration to selinux.
> That hadn't been necessary before since selinux simply didn't explicitly
> call the secondary->inode_setxattr() hook.
>
> Note I'm not arguing for or against, only arguing for caution :)

this sort of problem is possible with just a single LSM.

remember that unix doesn't try to make it impossible for the system owner 
to hang himself, becouse there are many other cases where the rope is used 
productivly. don't let the possibility that things can be done wrong 
prevent other people from being creative in ways that you never thought 
of.

David Lang
-
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