linux-kernel - Re: [PATCH 7/7] SLIM: documentation

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] [day] [month] [year] [list]

Message-Id: <1159286085.4718.4.camel@localhost.localdomain>
Date:	Tue, 26 Sep 2006 11:54:45 -0400
From:	David Safford <safford@...son.ibm.com>
To:	Pavel Machek <pavel@....cz>
Cc:	kjhall@...ibm.com, linux-kernel <linux-kernel@...r.kernel.org>,
	LSM ML <linux-security-module@...r.kernel.org>,
	David Safford <safford@...ibm.com>,
	Mimi Zohar <zohar@...ibm.com>,
	Serge E Hallyn <sergeh@...ibm.com>, akpm@...l.org
Subject: Re: [PATCH 7/7] SLIM: documentation

On Tue, 2006-09-19 at 21:16 +0200, Pavel Machek wrote: 
> Hi!
> 
> > Documentation.
> 
> Thanks for it.
> 
> > +file /etc/resolv.conf, dbus-daemon, which accepts data from
> > +potentially untrusted processes, Xorg, which has to accept data
> > +from all Xwindow clients, regardless of level, and postfix which
> > +delivers untrusted mail. Again, these applications inherently
> > +must cross trust levels, and SLIM properly identifies them.
> 
> How is this supposed to work. Xorg was not designed to be security
> barrier. So... your exploited evolution, but evolution is now
> UNTRUSTED, so you can't do anything interesting... right?
> 
> Wrong. evolution can ask Xorg to simulate "rm -rf /" keypresses, and
> send them to your shell in another window...

On one hand, I thought that allowSendEvents and editresBlock
specifically blocked synthetic keypresses from shell windows like 
xterm. On the other hand, I do agree that the X server
can provide dangerous communications between levels, and needs to
be fixed in some way. (dbus and Orbit have similar problems.)

Slim and selinux can control X access through socket labels, so there
are several options, based on your choice of policy:
  - you can run in "single level at a time" mode, in which all processes
    have to be at the same level, such as untrusted. This is safe, but
    pretty unusable, as you have to have separate logins for each level.
  - you can make the server a guard process, so that it can accept 
    connections from applications at any level. This is not generally
    safe as you point out, but is transparent to the user, and works
    for now.
  - you can add the necessary MAC checks into the X server, so that
    it enforces the local policy. This is safe, and convenient, but
    requires some patches to the server. NSA has started this work
    as part of LSM/selinux. See 
http://www.nsa.gov/selinux/papers/x11/t1.html

The documentation should have explained we are doing the second,
temporarily, until the X (and dbus, and Orbit) hooks are available.

dave


-
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/