FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 02-01-2010, 12:57 PM
Richard Hughes
 
Default Draft privilege escalation policy for comments

On 30 January 2010 07:33, Kevin Kofler <kevin.kofler@chello.at> wrote:
> The current PackageKit policy in F12 updates still allows upgrading (as
> opposed to installing or removing, not sure about downgrading, does
> PackageKit even support that?)

No, PackageKit won't let you downgrade a package.

> Is the bureaucracy in this section really necessary? AFAICT what was missing
> when the F12 PackageKit change was made was the informative part of the
> proposal, the maintainer just didn't know what he should be allowing and
> what not. I don't think the enforcement part is really needed, maintainers
> should be able to get it right on their own given the detailed list of evil
> things to avoid which the proposal provides and I haven't seen any evidence
> as to the contrary (again, the PackageKit example is not applicable because
> the PackageKit maintainer did NOT have such a list to go by when he made his
> change; there's no reason to believe he'd have made that change in spite of
> it).

Sure, if there was a policy document I would have never made the
Fedora change in the first place. I still think the original change
(to make signed packages installable by the local console user install
without a password) is the "right" upstream policy, but I will of
course ensure all my packages agree with whatever Fedora policy is
decreed. Luckily, with the new user account editor planned for F13, a
lot of these PackageKit security policy choices can be made more
intuitive.

Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-01-2010, 05:51 PM
Kevin Kofler
 
Default Draft privilege escalation policy for comments

Miloslav Trmańć wrote:
> That's not the intent: "mechanism" is "the code that causes running
> something as root", in this case DBus activation, not "the code running
> as root" (a DBus server).

Oh, if that's the intent, that's of course perfectly fine.

I'd be happy to provide any needed documentation about KAuth, but you'll
only really need it if you want to run checks on the source code, as KAuth
uses existing mechanisms (PolicyKit (both 1 and 0.9 are supported), D-Bus
activation) for the actual privilege escalation, it's just a source-level
abstraction layer (so for example, you won't find a PolicyKit policy in the
source code, but a KAuth policy which is converted to a PolicyKit policy at
build time).

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-01-2010, 10:18 PM
Adam Williamson
 
Default Draft privilege escalation policy for comments

On Sat, 2010-01-30 at 10:31 -0500, Colin Walters wrote:
> On Sat, Jan 30, 2010 at 1:20 AM, Adam Williamson <awilliam@redhat.com> wrote:
> >
> > Well, reboot is a one-time operation; if there's only one user logged
> > in, they can only affect themselves by rebooting. Adjusting the clock or
> > installing new software isn't the same.
>
> Ok, actually "one time" feels like there's a more general principle at
> work here, which is the degree to which the operation could
> potentially affect other users.

As it says in the second paragraph:

"An unprivileged user without administrative authentication must not be
able to change the behavior of the system "as a whole" (as viewed by
other users or by network clients), unless the system behavior is
intended to be dependent on the actions of the unprivileged user."

> For example, there's a pretty wide gulf between "install new desktop
> app" (other users see a new menu entry) and "start or stop system
> daemons" (can easily break printing, networking, or just crash the.
> Changing the system time is in between there.

> The reason I mention this specifically I'd like in the future to widen
> this set a little bit for the "self managed" desktop target (i.e.
> livecd download), specifically include at least "install new desktop
> application from " and "initiate system update" in that set of default
> privileges.

>From the Requirements preamble:

"In the case of an approved Fedora spin which automatically grants
administrative privileges to the first created user account,
authentication as that user can be considered administrative
authentication."
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-01-2010, 10:20 PM
Adam Williamson
 
Default Draft privilege escalation policy for comments

On Sun, 2010-01-31 at 08:55 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I think it's sensible, yeah. It's not really much bureaucracy; I don't
> > think it would ever be a good idea to introduce a new privilege
> > escalation mechanism without FESco knowing about it...
>
> Right now we're in a phase where a lot of stuff (system-config-*, several
> parts of KDE and some other stuff) is getting ported from running the whole
> app under consolehelper or kdesu to PolicyKit mechanisms. This is generally
> seen as a *good* thing. It'd be really annoying to have to go through a
> FESCo vote for every single one of those.

That's not intended to be the scope. It's not meant to mean that
introducing a PolicyKit policy requires a FESco review; it's meant to
mean that introducing *the entire PolicyKit mechanism* would have
required a FESco review.

Obviously (since you misunderstood it) the current wording is confusing,
I will try to improve it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 07:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org