On 05/01/2009 05:34 PM, Bruno Wolff III wrote:
On Fri, May 01, 2009 at 10:31:12 -0400,
Daniel J Walsh<dwalsh@xxxxxxxxxx> wrote:
I would like to run restorecond as a user service rather then as system
service. I want to run it under the Users UID and under with the users
context.
Then I can have it watch for creation of files in the users home
directory and be the equivalent of running restorecon ~/ by the user.
This seems to increase the risk of hostile apps being able to get executables
relabelled to something they couldn't do directly. If the app has the ability
to write the directory it can replace a file labelled with a label it couldn't
couldn't assign directly with another file and then wait for restorecond to
change the label.
While the same thing would happen with a relabel or running restorecon
manually, currently there is a lot more opportunity to discover the problem
before the file is relabelled.
The suggesting here is to use dbus to start applications in terminal
shell as the same user UID, not to have the system dbus start the app.
So I fail to see how this affects auditing. The goal here is to run
restorecond as my UID. Not Root. Adding some module to pam does not
help the multiple restorecond programs running, problem. And I still
have the problem of cleaning up in the pam stack on exit.
My thinking is we use dbus for setting up a session and it needs to be
in charge of cleaning up the session when all of the same UID's leave.
Otherwise every app that wants this functionality needs to do it.
The current restorecond as Bruno points out is a potential security
problem in a user can create a file and the restorecond can relabel it,
potentially to a label the user is not allowed to relabel to.
I know Nalin has looked into the potential for this as a better way of
doing kerberos ticket handling and ssh-agent. So there are other
potential users then restorecond.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
