On Wed, Oct 29, 2008 at 4:39 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Wednesday 29 October 2008 15:25:15 Colin Walters wrote:
> On Wed, Oct 29, 2008 at 3:13 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > 1) We've spent a lot of time on getting audit right. We can tell what
> > account was logged in under and find every single application that was
> > started as a result of that login. Message passing breaks this.
>
> True, though how interesting is the question of "what binaries were
> executed" as opposed to the system having enough intelligence to
> display security-relevant information?
Not sure I follow your question. I am talking about /proc/<pid>/loginuid and
sessionid.
Oh. Well, if your application uses PolicyKit there are *two*
programs; the privileged mechanism, and the unprivileged application.
The unprivileged application of course maintains the loginuid.
No this is about PolicyKit being another MAC system that needs
configuring.
Of course it would be ideal if there were One True MAC system, but
AFAIK the story on SELinux is still that the system must be secure
without it, and other vendors that we care about from the desktop
perspective (personally I just care about Ubuntu and OpenSolaris)
haven't yet finished integrating it. Even when we do depend on
SELinux (and I would advocate that), PolicyKit fills a useful role as
"coarse grained" system on top of the far more fine grained SELinux
policy. Also, by having application authors forced to split
applications into privileged mechanisms and unprivileged frontends,
the SELinux policy for the mechanism can be much stronger.
Where's the GUI or commandline tool that lets me configure it? I
may need to
have auditing of who changed what entry in that file. When I chmod 4755 a
program, I know who changed it, what the old and new values are, when they
did it, and what the outcome was.
There's no real story on that other than "uid 0" and $EDITOR yet.
This is basically the same as all the other OS config files.
True...but this is a discussion that needs to be had so that it can
be fixed.
Auditing from user space is not trustworthy and that's why its done from the
kernel.
Hmm? SELinux userspace enforcers (dbus and X.org) are using the audit
system; I don't think it's reasonable to say that the kernel is the
only component of the TCB.