Re: PolicyKit and syslog -- now bug #541040

[Matthew Miller]

On Tue, Nov 24, 2009 at 02:38:42PM -0500, Matthew Miller wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=541040

So one thing that occurs to me as soon as I start poking at the code -- it's
relatively easy to have it emit a log message when a policy file is changed,
but this is largely useless because there's no way to verify the policy
state _at startup_.

So I think it's probably better to leave that aspect to more traditional
tools for monitoring file changes.

-- 
Matthew Miller 
Senior Systems Architect 
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

PolicyKit and syslog -- now bug #541040

[Matthew Miller]

On Tue, Nov 24, 2009 at 11:47:03AM -0500, Seth Vidal wrote:
> I'd recommend filing this as a bug.

Bug 541040 -  Enable logging in PolicyKit (for policy changes and for 
authorizations.)

https://bugzilla.redhat.com/show_bug.cgi?id=541040


-- 
Matthew Miller   mat...@mattdm.org  

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: Security testing: need for a security policy, and a security-critical package process

[Adam Williamson]

On Tue, 2009-11-24 at 10:44 -0800, Adam Williamson wrote:

> As I noted somewhat flippantly in another thread, this comes with the
> problem that, theoretically, a user who has the privileges to install
> packages at a relaxed security level could arbitrarily raise the
> security level of the system to a much higher level, against the wishes
> of the administrator.
> 
> perhaps something akin to system-config-selinux would be needed to guard
> against this? I'm not sure how it could work in the PolicyKit framework,
> though.

or, I suppose more trivially, a PackageKit policy for the ability to
install PolicyKit policy packages. heh, now that's a bizarre sentence.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: tangent: PolicyKit and PAM

[Seth Vidal]

On Tue, 24 Nov 2009, Matthew Miller wrote:


On Tue, Nov 24, 2009 at 01:27:40PM -0500, Matthias Clasen wrote:

Like I said, this is a tangent, and I'm certainly not expecting anyone to
work on this. But it'd be cool if they did.

Just as everybody else is struggling to get away from pam's awful
apis...I don't think this would be a step forward; but sure, it might be
doable.


The awful API is actually an argument _for_ doing such a thing: it gets
encapsulated away in only one place that needs to be maintained, and
everyone can just write to PolicyKit.



And in general having the logging of security-elevation events be in the 
lowest common denominator piece of code or interface keeps important 
information from getting lost due to insufficient logging in a calling app.


-sv

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: Security testing: need for a security policy, and a security-critical package process

[Seth Vidal]

On Tue, 24 Nov 2009, Bill Nottingham wrote:


I don't want to ship a desktop that doesn't let the user do useful
things.


And you can ship a desktop SPIN that way. But the base pkgs should
not install with an insecure set of choices.

if you want the spin to have a post-scriptlet which allows more
things, then that's the choice of the desktop sig over the desktop
spin.


Given how .pkla works, this is likely to be done with packages, not
with %post hackery. (Which should make it much easier to reliably
test, as well.)


provided those pkgs are not required anywhere or set in our default pkg 
groups, then sure.


-sv

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: Security testing: need for a security policy, and a security-critical package process

[Adam Williamson]

On Tue, 2009-11-24 at 13:28 -0500, Bill Nottingham wrote:
> > >I don't want to ship a desktop that doesn't let the user do useful
> > >things.
> > 
> > And you can ship a desktop SPIN that way. But the base pkgs should
> > not install with an insecure set of choices.
> > 
> > if you want the spin to have a post-scriptlet which allows more
> > things, then that's the choice of the desktop sig over the desktop
> > spin.
> 
> Given how .pkla works, this is likely to be done with packages, not
> with %post hackery. (Which should make it much easier to reliably
> test, as well.)

As I noted somewhat flippantly in another thread, this comes with the
problem that, theoretically, a user who has the privileges to install
packages at a relaxed security level could arbitrarily raise the
security level of the system to a much higher level, against the wishes
of the administrator.

perhaps something akin to system-config-selinux would be needed to guard
against this? I'm not sure how it could work in the PolicyKit framework,
though.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: tangent: PolicyKit and PAM

[Matthew Miller]

On Tue, Nov 24, 2009 at 01:27:40PM -0500, Matthias Clasen wrote:
> > Like I said, this is a tangent, and I'm certainly not expecting anyone to
> > work on this. But it'd be cool if they did.
> Just as everybody else is struggling to get away from pam's awful
> apis...I don't think this would be a step forward; but sure, it might be
> doable. 

The awful API is actually an argument _for_ doing such a thing: it gets
encapsulated away in only one place that needs to be maintained, and
everyone can just write to PolicyKit.

Annd speaking of tangents and horrible interfaces, I should add that one
thing I'm very genuinely happy to learn in all of this is that the pkla config
files are key=value rather than the old PolicyKit.conf xml file. So much
nicer for humans to work with!

-- 
Matthew Miller 
Senior Systems Architect 
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: tangent: PolicyKit and PAM

[Matthias Clasen]

On Tue, 2009-11-24 at 13:18 -0500, Matthew Miller wrote:

> Like I said, this is a tangent, and I'm certainly not expecting anyone to
> work on this. But it'd be cool if they did.

Just as everybody else is struggling to get away from pam's awful
apis...I don't think this would be a step forward; but sure, it might be
doable. 

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: Security testing: need for a security policy, and a security-critical package process

[Bill Nottingham]

> >I don't want to ship a desktop that doesn't let the user do useful
> >things.
> 
> And you can ship a desktop SPIN that way. But the base pkgs should
> not install with an insecure set of choices.
> 
> if you want the spin to have a post-scriptlet which allows more
> things, then that's the choice of the desktop sig over the desktop
> spin.

Given how .pkla works, this is likely to be done with packages, not
with %post hackery. (Which should make it much easier to reliably
test, as well.)

Bill

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

tangent: PolicyKit and PAM

[Matthew Miller]

On Tue, Nov 24, 2009 at 12:44:00PM -0500, Matthias Clasen wrote:
> > 1. In fact, a PAM-backed authority for PolicyKit might be interesting and
> > useful -- but there's a tangent.
> What do you think PolicyKit is using for authentication ?
> See 
> http://cgit.freedesktop.org/PolicyKit/tree/src/polkitagent/polkitagenthelper.c

It uses it for authentication *and* for authorization, but it uses one
service name (polkit-1) for everything (which is in turn configured by
default to just defer to the standard system-auth service definition). This
arrangement isn't particularly useful for a flexible authorization policy.

You can use it for the big-hammer "user-is-locked out" stuff, but not for
things like "local users can install packages without a password, only
during business hours", which PAM is perfectly expressive enough to do (with
existing modules, even).

I don't think, offhand, that it could be quite as flexible as the Local
Authority currently in PolicyKit or via some fancy LDAP Authority, but I
don't think it necessarily would need to be. The main advantage would be
that instead of having yet another way (and again, I want to emphasize that
I think PolicyKit is good work) to implement authorization policy, one could
use PolicyKit with a well-understood mechanism that's been in production use
since the 90s.

Like I said, this is a tangent, and I'm certainly not expecting anyone to
work on this. But it'd be cool if they did.

-- 
Matthew Miller 
Senior Systems Architect 
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: PolicyKit and syslog

[Matthias Clasen]

On Tue, 2009-11-24 at 12:29 -0500, Matthew Miller wrote:


> 1. In fact, a PAM-backed authority for PolicyKit might be interesting and
> useful -- but there's a tangent.

What do you think PolicyKit is using for authentication ?

See 
http://cgit.freedesktop.org/PolicyKit/tree/src/polkitagent/polkitagenthelper.c


--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: PolicyKit and syslog

[Matthew Miller]

On Tue, Nov 24, 2009 at 11:47:03AM -0500, Seth Vidal wrote:
> I'd recommend filing this as a bug.

I definitely will -- I just want to get some feedback first.

-- 
Matthew Miller   mat...@mattdm.org  

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: PolicyKit and syslog

[Matthew Miller]

On Tue, Nov 24, 2009 at 11:35:13AM -0500, Matthias Clasen wrote:
> PolicyKit itself is not running anything. It is just answering the
> question of a mechanism: 'is X allowed to do foo ?'. It would make more
> sense for the mechanisms that use PolicyKit to log privileged actions
> that they do or deny to do. 

That makes sense. However, I can see strengths in both approaches. 

A good analogy is PAM, particularly the "auth" section, which does basically
the same thing¹ as PolicyKit. There, you get logs both from the application
itself and from PAM directly.

There are four particular strengths I see in logging at the PolicyKit
level.

 1) Existing applications don't need to be changed, and new applications
don't need to be counted on to do the right thing. Appropriate logging
just starts happening.

 2) Log levels and debugging are easier to admin because there's a central
configuration (and PolicyKit already has config files). If I want to
turn on more authentication 

 3) Log messages are automatically consistent between programs, making
analysis and monitoring much easier.

 4) PolicyKit is in a position to log more about the decisions it makes
than is (or should be) exposed to the client application. This can be
particularly useful for debugging but may also be useful for auditing.
(If a user was allowed access for a certain reason, and that reason
turns out to be something they shouldn't have access to but do,
we can know to investigate.)

Also, since this is a security/auditing issue, I thing it's never wrong to
error on the side of more logging.

I absolutely agree that client applications should also log their
elevated-privilege actions.





1. In fact, a PAM-backed authority for PolicyKit might be interesting and
useful -- but there's a tangent.


-- 
Matthew Miller 
Senior Systems Architect 
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: PolicyKit and syslog

[Seth Vidal]

On Tue, 24 Nov 2009, Matthias Clasen wrote:


On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote:





when the policies are updated it is policy kit that has to be involved.
polkitd is running, at least.


That might be ok to log, indeed. polkitd need not be running, though. It
is activated as needed.


It would make sense for polkitd to note a change to a policy. Maybe also
to note any communications to polkitd of any kind.


That I would consider spamming. But maybe at absurd log levels...


Policy changes should be warning level notices b/c it notes a change in 
state.


any/all communication should be at debug level notices.

debugging is a lot easier when you can follow the whole process along.


-sv





--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: PolicyKit and syslog

[Matthias Clasen]

On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote:

> >
> 
> when the policies are updated it is policy kit that has to be involved. 
> polkitd is running, at least.

That might be ok to log, indeed. polkitd need not be running, though. It
is activated as needed.

> It would make sense for polkitd to note a change to a policy. Maybe also 
> to note any communications to polkitd of any kind.

That I would consider spamming. But maybe at absurd log levels...


--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: PolicyKit and syslog

[Seth Vidal]

On Tue, 24 Nov 2009, Matthias Clasen wrote:


On Tue, 2009-11-24 at 11:26 -0500, Matthew Miller wrote:

One of the important features of sudo is its ability to log elevated-access
actions to syslog.

Userhelper similarly logs actions, like so: "userhelper[26491]: running
'/usr/share/system-config-users/system-config-users ' with root privileges
on behalf of 'mattdm'".

PolicyKit serves a similar function, but doesn't seem to log anything.

In fact, the only use of syslog appears to be in polkit-agent-helper-1,
which logs in two possible situations -- when called with the wrong number
of arguments and when stdin is a tty. (Most other things it fprintfs to
stderr.)

I'm not bringing this up to complain -- I just want to make sure that I'm
not missing something (which happens more often than it should; *sigh*). If
I'm not missing something, is this something anyone is working on already or
has existing plans for?



PolicyKit itself is not running anything. It is just answering the
question of a mechanism: 'is X allowed to do foo ?'. It would make more
sense for the mechanisms that use PolicyKit to log privileged actions
that they do or deny to do.



when the policies are updated it is policy kit that has to be involved. 
polkitd is running, at least.


It would make sense for polkitd to note a change to a policy. Maybe also 
to note any communications to polkitd of any kind.


-sv

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: PolicyKit and syslog

[Seth Vidal]

On Tue, 24 Nov 2009, Matthew Miller wrote:


One of the important features of sudo is its ability to log elevated-access
actions to syslog.

Userhelper similarly logs actions, like so: "userhelper[26491]: running
'/usr/share/system-config-users/system-config-users ' with root privileges
on behalf of 'mattdm'".

PolicyKit serves a similar function, but doesn't seem to log anything.

In fact, the only use of syslog appears to be in polkit-agent-helper-1,
which logs in two possible situations -- when called with the wrong number
of arguments and when stdin is a tty. (Most other things it fprintfs to
stderr.)

I'm not bringing this up to complain -- I just want to make sure that I'm
not missing something (which happens more often than it should; *sigh*). If
I'm not missing something, is this something anyone is working on already or
has existing plans for?



I see nothing noting any changes to the policy state whatsoever.

I'd recommend filing this as a bug.

thanks,
-sv

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: PolicyKit and syslog

[Matthias Clasen]

On Tue, 2009-11-24 at 11:26 -0500, Matthew Miller wrote:
> One of the important features of sudo is its ability to log elevated-access
> actions to syslog.
> 
> Userhelper similarly logs actions, like so: "userhelper[26491]: running
> '/usr/share/system-config-users/system-config-users ' with root privileges
> on behalf of 'mattdm'".
> 
> PolicyKit serves a similar function, but doesn't seem to log anything.
> 
> In fact, the only use of syslog appears to be in polkit-agent-helper-1,
> which logs in two possible situations -- when called with the wrong number
> of arguments and when stdin is a tty. (Most other things it fprintfs to
> stderr.)
> 
> I'm not bringing this up to complain -- I just want to make sure that I'm
> not missing something (which happens more often than it should; *sigh*). If
> I'm not missing something, is this something anyone is working on already or
> has existing plans for?
> 

PolicyKit itself is not running anything. It is just answering the
question of a mechanism: 'is X allowed to do foo ?'. It would make more
sense for the mechanisms that use PolicyKit to log privileged actions
that they do or deny to do. 

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

PolicyKit and syslog

[Matthew Miller]

One of the important features of sudo is its ability to log elevated-access
actions to syslog.

Userhelper similarly logs actions, like so: "userhelper[26491]: running
'/usr/share/system-config-users/system-config-users ' with root privileges
on behalf of 'mattdm'".

PolicyKit serves a similar function, but doesn't seem to log anything.

In fact, the only use of syslog appears to be in polkit-agent-helper-1,
which logs in two possible situations -- when called with the wrong number
of arguments and when stdin is a tty. (Most other things it fprintfs to
stderr.)

I'm not bringing this up to complain -- I just want to make sure that I'm
not missing something (which happens more often than it should; *sigh*). If
I'm not missing something, is this something anyone is working on already or
has existing plans for?



-- 
Matthew Miller 
Senior Systems Architect 
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list

Re: Security testing: need for a security policy, and a security-critical package process

[Toshio Kuratomi]

On Mon, Nov 23, 2009 at 06:10:59PM -0800, Adam Williamson wrote:
> On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote:
> 
> > How that translates in packages and defaults is not really the most
> > important part, but the plan is to have strict package defaults + a
> > policy package that makes things work. 
> > 
> > The important part is that we QA the combination, not just the strict
> > defaults. 
> 
> Right. If the Grand Plan is to go down this path, then what I've been
> referring to as 'the security policy' would include the policies defined
> for each spin, and hence any testing QA did for any given spin would
> involve the policy defined for that spin.
> 
> Having said that - is everyone agreeing that it's fine for each spin SIG
> to be entirely in charge of defining and implementing security policy
> for each spin? At the very least, that would possibly be problematic
> given the known border issues between 'the desktop spin' and 'Fedora'.
> Just another issue contributing to why we would need to settle that.
> 
I'm very much against that.  Fedora, Linux, and Unix-like operating systems
have built a reputation as a more secure alternative to Windows and other
operating systems.  We have to have some level of security that comes
enabled on all systems no matter what the spin.

Also, conflating "Fedora" with the "Desktop Spin" is something I'm very
uncomfortable with here.  A spin meant to highlight what the authors think
is the most convenient experience for a single user desktop system
apparently wants to do things that I am not at all for highlighting as the
default Fedora environment.  We need to separate these so that the Desktop
Spin can live its own life without the additional constraints of being
Fedora.

-Toshio


pgpEEyYzVtIQh.pgp
Description: PGP signature
--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list