After seeing two conflicts over PolicyKit default policies allowing unprivileged to do things that previously only root could do, it seems to me that there needs to be some kind of oversight on security policy for the distribution. Right now, any package maintainer can make changes to system security policy, without announcing it, getting any approval, etc.
In the two cases I've seen, the maintainers decided that their way was the right way and closed the bug reports without any real discussion, which just seems unacceptable to me.
Any package (whether new or an update) that adds/changes PolicyKit, consolehelper, or PAM configuration, and anything that installs new setuid/setgid executables, should require some additional third-party review. Any significant changes that passes review should require some minimum amount of advance notice and documentation on how to revert (preferably in some common easy-to-find place in the wiki).
Is this feasible? Who needs to look at this?
I would like to see this discussion separate from discussion about the current issue with PackageKit.
On Wed, 2009-11-18 at 17:58 -0600, Chris Adams wrote:
Any package (whether new or an update) that adds/changes PolicyKit, consolehelper, or PAM configuration, and anything that installs new setuid/setgid executables, should require some additional third-party review. Any significant changes that passes review should require some minimum amount of advance notice and documentation on how to revert (preferably in some common easy-to-find place in the wiki).
Is this feasible?
Looks like a very good idea to me.
Who needs to look at this?
Fesco ?
Simo.
On Wed, 18 Nov 2009, Simo Sorce wrote:
On Wed, 2009-11-18 at 17:58 -0600, Chris Adams wrote:
Any package (whether new or an update) that adds/changes PolicyKit, consolehelper, or PAM configuration, and anything that installs new setuid/setgid executables, should require some additional third-party review. Any significant changes that passes review should require some minimum amount of advance notice and documentation on how to revert (preferably in some common easy-to-find place in the wiki).
Is this feasible?
Looks like a very good idea to me.
I think that's too subjective though. I'd be more in favor of a simple, broad view of what the user should be able to do without root. It's possible "install packages" would be on that list, it's possible not. That way packages could ask themselves "does this break the policy?" If it doesn't, great. If it does, time for a bug report.
Better then a review process because then everyone would generally know what to expect.
-Mike
On Wed, Nov 18, 2009 at 6:37 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 18 Nov 2009, Simo Sorce wrote:
On Wed, 2009-11-18 at 17:58 -0600, Chris Adams wrote:
Any package (whether new or an update) that adds/changes PolicyKit, consolehelper, or PAM configuration, and anything that installs new setuid/setgid executables, should require some additional third-party review. Â Any significant changes that passes review should require some minimum amount of advance notice and documentation on how to revert (preferably in some common easy-to-find place in the wiki).
Is this feasible?
Looks like a very good idea to me.
I think that's too subjective though. Â I'd be more in favor of a simple, broad view of what the user should be able to do without root. Â It's possible "install packages" would be on that list, it's possible not. That way packages could ask themselves "does this break the policy?" Â If it doesn't, great. Â If it does, time for a bug report.
Better then a review process because then everyone would generally know what to expect.
-Mike
I agree. I think that's easier rather than trying to understand the specifics of each package.
stahnma
On 11/18/2009 07:37 PM, Mike McGrath wrote:
I think that's too subjective though. I'd be more in favor of a simple, broad view of what the user should be able to do without root. It's possible "install packages" would be on that list, it's possible not. That way packages could ask themselves "does this break the policy?" If it doesn't, great. If it does, time for a bug report.
Better then a review process because then everyone would generally know what to expect.
Agreed, that makes more sense and is more scalable.
Jeff
Once upon a time, Mike McGrath mmcgrath@redhat.com said:
I think that's too subjective though.
What is subjective about "allowing unprivileged to do things that previously only root could do"?
I'd be more in favor of a simple, broad view of what the user should be able to do without root. It's possible "install packages" would be on that list, it's possible not. That way packages could ask themselves "does this break the policy?" If it doesn't, great. If it does, time for a bug report.
There have been bug reports, but they get closed by the maintainers as NOTABUG, so that procedure is obviously not working.
On 11/18/2009 08:11 PM, Chris Adams wrote:
Once upon a time, Mike McGrath mmcgrath@redhat.com said:
I think that's too subjective though.
What is subjective about "allowing unprivileged to do things that previously only root could do"?
I'd be more in favor of a simple, broad view of what the user should be able to do without root. It's possible "install packages" would be on that list, it's possible not. That way packages could ask themselves "does this break the policy?" If it doesn't, great. If it does, time for a bug report.
There have been bug reports, but they get closed by the maintainers as NOTABUG, so that procedure is obviously not working.
This conclusion doesn't make a whole lot of sense. There's no guideline in place, so package maintainers aren't given the guidance Mike's suggesting. Without that guidance, closed->NOTABUG is not an indication of whether this process works, because there's no process being followed.
To be perfectly frank, "any packager has the power to change behavior" is exactly how it should be. Right now developers using PK are basically deciding policy on their own, with no guidance as to the grander plan, and people are evaluating the quality of these decisions without a real, tangible reference point. There does need to be a way for a developer or packager to know if or how they /should/ be changing security-relevant behaviors, and for others to evaluate if the change is good or bad.
Mike's suggestion of a distro-wide policy is one way to do that, and on it's face, it's certainly a lot more practical than a distro wide change control board auditing for security relevant changes, or even sillier, expecting package maintainers to identify when a change has security implications and come asking what they should do. A "command" infrastructure does not fit Fedora or Linux very well.
I think the policy should be in two parts, though. Mike's suggestion is good; we need general guidelines as to what roles which classes of users are expected to fulfill. We probably also need some packaging policy for applications providing escalated privileges via policy kit, like we already have for setuid utilities.
On Thu, 2009-11-19 at 10:05 -0500, Peter Jones wrote:
Mike's suggestion of a distro-wide policy is one way to do that, and on it's face, it's certainly a lot more practical than a distro wide change control board auditing for security relevant changes, or even sillier, expecting package maintainers to identify when a change has security implications and come asking what they should do. A "command" infrastructure does not fit Fedora or Linux very well.
I think the policy should be in two parts, though. Mike's suggestion is good; we need general guidelines as to what roles which classes of users are expected to fulfill. We probably also need some packaging policy for applications providing escalated privileges via policy kit, like we already have for setuid utilities.
I am in strong agreement here. A guiding (set of) polic{y,ies} is what is needed, to help the maintainers who have control make decisions that fit well with what the Fedora project (or individual spin) is trying to offer. We don't need more rubber stamp meetings, just better guidelines.
Should this be part of the Packaging guidelines, or a different set of design guidelines?
On Wed, Nov 18, 2009 at 7:37 PM, Mike McGrath mmcgrath@redhat.com wrote:
I think that's too subjective though. Â I'd be more in favor of a simple,
How is this subjective? At one time it was the norm that you had to justify a SUID 0 binary. Packagekit is basically allowing the same thing through other means. It should be subject to at least the same scrutiny.
broad view of what the user should be able to do without root. Â It's possible "install packages" would be on that list, it's possible not. That way packages could ask themselves "does this break the policy?" Â If it doesn't, great. Â If it does, time for a bug report.
Better then a review process because then everyone would generally know what to expect.
Some kind of review and disclosure should still be required because security holes can be astonishingly difficult to spot as bugs, yet utterly trivial to exploit.
The time configuration policy is actually a fantastic example of this: After it was pointed out that any user could change the time willy-nilly the complaint was disregarded and denied by many because the dialog *did* ask for a password, as would be the classic unix security model expectation. Except… it was asking for the *users* password rather than a root password— so if you happen to know both (or if they are the same) you could test it and fail to realize that it was violating the long-standing expectation.
There is also the significant possibility of policy interaction. A sufficiently general policy (i.e. one which isn't just the policykit policy) could possibly permit configurations which are acceptable in isolation but which are hazardous in practice.
E.g. perhaps one policy permits the install of packages from pre-configured repos and another policy permits the user to add repos (to make it easy to navigate them in the package management interface).
(Not the adding packages from existing repos isn't already a terrible security hole: Unless you have very specific rules about the default configuration of packages in the repo it's likely that some of the packages will violate the security expectations when installed)
Gregory Maxwell wrote:
The time configuration policy is actually a fantastic example of this: After it was pointed out that any user could change the time willy-nilly the complaint was disregarded and denied by many because the dialog *did* ask for a password, as would be the classic unix security model expectation. Except… it was asking for the *users* password rather than a root password— so if you happen to know both (or if they are the same) you could test it and fail to realize that it was violating the long-standing expectation.
FWIW, upstream KDE requires root authentication to set the current time, and in fact one usage (the one usage? I haven't found others so far) of KAuth in KDE 4.4 will be to use PolicyKit to prompt for the root password (KDE 4.3 uses kdesu there). So now we also have inconsistent system policies, with one tool explicitly prompting for root and another one not doing it. :-(
Kevin Kofler
On Thu, 2009-11-19 at 03:04 +0100, Kevin Kofler wrote:
FWIW, upstream KDE requires root authentication to set the current time, and in fact one usage (the one usage? I haven't found others so far) of KAuth in KDE 4.4 will be to use PolicyKit to prompt for the root password (KDE 4.3 uses kdesu there). So now we also have inconsistent system policies, with one tool explicitly prompting for root and another one not doing it. :-(
If you are using 2 different policies to do the same thing you are doing something very wrong, you should use the same exact policy both for KDE and GNOME and any other program that allows any non-root-user to change the time on the computer.
Simo.
Simo Sorce wrote:
If you are using 2 different policies to do the same thing you are doing something very wrong, you should use the same exact policy both for KDE and GNOME and any other program that allows any non-root-user to change the time on the computer.
Well, that's an upstream issue, really. And perhaps more importantly, KDE uses PolicyKit policies autogenerated from "KAuth actions", so I don't know how feasible it is to make it use a policy defined by something different instead. KAuth is designed to hide the details of PolicyKit from developers (in fact, there is even a Mac backend using OS X's authentication&authorization framework instead).
Kevin Kofler
On Wed, 2009-11-18 at 17:58 -0600, Chris Adams wrote:
Any package (whether new or an update) that adds/changes PolicyKit, consolehelper, or PAM configuration, and anything that installs new setuid/setgid executables, should require some additional third-party review. Any significant changes that passes review should require some minimum amount of advance notice and documentation on how to revert (preferably in some common easy-to-find place in the wiki).
Is this feasible? Who needs to look at this?
Previously discussed here: http://www.redhat.com/archives/rhl-devel-list/2009-August/msg00578.html
Tim. */
2009/11/18 Chris Adams cmadams@hiwaay.net:
I would like to see this discussion separate from discussion about the current issue with PackageKit.
That would be nice :)
The problem is who to target. If you call Fedora a desktop distro, then it makes perfect sense for local users to be able to shutdown the computer, suspend, change the system clock and install clipart without passwords, as long as it's done in a secure way.
If you call Fedora a server OS, then it shouldn't be shipping PackageKit at all, and should have most of the PolicyKit authentication actions defaulting to no.
So obviously we need some middle ground. I guess if the spins "personalise" the package set then they should also personalize the security defaults. e.g. a server spin would not include PackageKit at all, and default to not letting users change the time. A desktop spin would allow the desktop user to do most things without a administrator password. The tricky part is deciding a default policy that is suitable for all the people using Fedora, which honestly, I think is impossible.
Richard.
On 11/19/2009 04:45 PM, Richard Hughes wrote:
So obviously we need some middle ground. I guess if the spins "personalise" the package set then they should also personalize the security defaults. e.g. a server spin would not include PackageKit at all, and default to not letting users change the time. A desktop spin would allow the desktop user to do most things without a administrator password. The tricky part is deciding a default policy that is suitable for all the people using Fedora, which honestly, I think is impossible.
Right. The alternative really is defining the roles and the target audience clearly for distinct set of policies and allowing the user to trivially select it during or post-installation.
So if I pick "personal desktop", the change you made makes sense. If on the other hand, I choose "workstation" profile, I would obviously need a more locked down profile.
Rahul
2009/11/19 Rahul Sundaram sundaram@fedoraproject.org:
Right. The alternative really is defining the roles and the target audience clearly for distinct set of policies and allowing the user to trivially select it during or post-installation.
I disagree, most people will just go for the default option without understanding the subtle nuances of what they are being asked.
So if I pick "personal desktop", the change you made makes sense. If on the other hand, I choose "workstation" profile, I would obviously need a more locked down profile.
Surely if you're deploying a workstation (1000s of workstations?) you would just ship an extra package that set the PolicyKit policies according to the domain policy, so if I was a school, I would allow the active users to unplug removable drives, but not detach physical drives. I would also stop them installing and upgrading (not even give them the option to enter a root password) and also lock down who can change the clock. I would also prevent them from installing debuginfo files and being able to set thier audio system to real-time priority.
The real argument is what set of users upstream software should target. There's an argument for upstream to default to "no" for all actions and for the admin to install a policy for "desktop", "workstation" etc, but then there's just the related problem of what policy package to choose by default for "Fedora".
Richard.
On Thu, 2009-11-19 at 11:45 +0000, Richard Hughes wrote:
Surely if you're deploying a workstation (1000s of workstations?) you would just ship an extra package that set the PolicyKit policies according to the domain policy, so if I was a school, I would allow the active users to unplug removable drives, but not detach physical drives. I would also stop them installing and upgrading (not even give them the option to enter a root password) and also lock down who can change the clock. I would also prevent them from installing debuginfo files and being able to set thier audio system to real-time priority.
FWIW, what I set up for our school's Fedora 11 workstations is here: http://jdieter.fedorapeople.org/lesbg-polkit-setup-client.spec
There are definitely some ways I could clean it up, but it at least keeps me from having students installing software (or running updates) without permission.
Jonathan
2009/11/19 Richard Hughes hughsient@gmail.com
So if I pick "personal desktop", the change you made makes sense. If on the other hand, I choose "workstation" profile, I would obviously need a more locked down profile.
Surely if you're deploying a workstation (1000s of workstations?) you would just ship an extra package that set the PolicyKit policies according to the domain policy, so if I was a school, I would allow the active users to unplug removable drives, but not detach physical drives. I would also stop them installing and upgrading (not even give them the option to enter a root password) and also lock down who can change the clock. I would also prevent them from installing debuginfo files and being able to set thier audio system to real-time priority.
The real argument is what set of users upstream software should target. There's an argument for upstream to default to "no" for all actions and for the admin to install a policy for "desktop", "workstation" etc, but then there's just the related problem of what policy package to choose by default for "Fedora".
Why not choose them all?
What about having packaged policy profiles?
policykit-profile-i-am-paranoid policykit-profile-server policykit-profile-controlled-deployment policykit-profile-personal-desktop
In the live CD install the last one by default, on the DVD, choose the server option. Either way, since it is a packaged profile, all someone will need to do to change to a different one is replace the RPM package with something appropriate.
In this case, I do not think it is an either/or situation.
2009/11/19 Naheem Zaffar naheemzaffar@gmail.com:
policykit-profile-server policykit-profile-controlled-deployment policykit-profile-personal-desktop
Sure, that's not an insane idea at all. I would imagine most network admins worth their salt would be shipping custom PolicyKit overrides in F12 anyway. Aim for the desktop use cases on the "Desktop" spin, and let other spins change the defaults.
Richard.
On Thu, Nov 19, 2009 at 12:32:50PM +0000, Richard Hughes wrote:
2009/11/19 Naheem Zaffar naheemzaffar@gmail.com:
policykit-profile-server policykit-profile-controlled-deployment policykit-profile-personal-desktop
Sure, that's not an insane idea at all. I would imagine most network admins worth their salt would be shipping custom PolicyKit overrides in F12 anyway. Aim for the desktop use cases on the "Desktop" spin, and let other spins change the defaults.
It makes sense to me for the upstream defaults to be fairly restrictive, with changes being made downstream in distros (and their remixes/spins) to loosen those up as needed. In other words, our desktop package group would include whatever was needed to induce the desired behavior in the Desktop spin. A good bit of this issue would need to be addressed upstream though. (Maybe I just repeated what you said, not sure if I caught the nuance.)
2009/11/19 Paul W. Frields stickster@gmail.com:
It makes sense to me for the upstream defaults to be fairly restrictive, with changes being made downstream in distros (and their remixes/spins) to loosen those up as needed. Â In other words, our desktop package group would include whatever was needed to induce the desired behavior in the Desktop spin. Â A good bit of this issue would need to be addressed upstream though. Â (Maybe I just repeated what you said, not sure if I caught the nuance.)
Yes, this makes a lot of sense, and if I was to redo the F12 experience again this is what I would have done. At the moment we're asking the server spin to essentially close the door, when maybe we should start with a closed door, and be asking the desktop spin to open it up a little more.
Richard.
On Thu, 2009-11-19 at 13:38 +0000, Richard Hughes wrote:
2009/11/19 Paul W. Frields stickster@gmail.com:
It makes sense to me for the upstream defaults to be fairly restrictive, with changes being made downstream in distros (and their remixes/spins) to loosen those up as needed. In other words, our desktop package group would include whatever was needed to induce the desired behavior in the Desktop spin. A good bit of this issue would need to be addressed upstream though. (Maybe I just repeated what you said, not sure if I caught the nuance.)
Yes, this makes a lot of sense, and if I was to redo the F12 experience again this is what I would have done. At the moment we're asking the server spin to essentially close the door, when maybe we should start with a closed door, and be asking the desktop spin to open it up a little more.
It's a point I've made elsewhere, but I'm not sure it's perfectly okay to keep talking about 'the desktop spin'. First of all, this does not only affect the desktop live image: it also affects a default install from either the DVD image or a network install. PackageKit is installed by default in both those cases.
(I wouldn't be surprised if it's also on the Xfce and LXDE spins too, btw).
Second of all, the general perception of 'the desktop spin' is not 'the desktop spin'. The general perception, helped by how our download page set up, is that 'the desktop spin' is Fedora, or at least the three methods mentioned above - desktop spin, DVD, network install - are Fedora. Most people who are not quite active Fedora project members, and probably even a lot of those, see the desktop spin as 'default Fedora', not as a special-interest spin like the KDE or XFCE spins. Whether that's right or not is a question to be looked at, but we have to take into account that that's how things are generally seen at present.
Third of all, though this has been implied already, it's worth explicitly stating: the policy change was not made in 'the desktop spin'. It wasn't even made in Fedora's PackageKit package. It was made upstream. Upstream PackageKit comes configured to allow trusted package installation without authentication.
Adam Williamson wrote:
It's a point I've made elsewhere, but I'm not sure it's perfectly okay to keep talking about 'the desktop spin'. First of all, this does not only affect the desktop live image: it also affects a default install from either the DVD image or a network install. PackageKit is installed by default in both those cases.
(I wouldn't be surprised if it's also on the Xfce and LXDE spins too, btw).
It's also on the KDE spin. KPackageKit uses the same PackageKit behind the scenes as gnome-packagekit.
And besides, I don't see this policy change as being appropriate even for the GNOME desktop spin.
Kevin Kofler
On Thu, 2009-11-19 at 08:29 -0500, Paul W. Frields wrote:
On Thu, Nov 19, 2009 at 12:32:50PM +0000, Richard Hughes wrote:
2009/11/19 Naheem Zaffar naheemzaffar@gmail.com:
policykit-profile-server policykit-profile-controlled-deployment policykit-profile-personal-desktop
Sure, that's not an insane idea at all. I would imagine most network admins worth their salt would be shipping custom PolicyKit overrides in F12 anyway. Aim for the desktop use cases on the "Desktop" spin, and let other spins change the defaults.
It makes sense to me for the upstream defaults to be fairly restrictive, with changes being made downstream in distros (and their remixes/spins) to loosen those up as needed. In other words, our desktop package group would include whatever was needed to induce the desired behavior in the Desktop spin. A good bit of this issue would need to be addressed upstream though. (Maybe I just repeated what you said, not sure if I caught the nuance.)
This idea comes up a lot - that we can make Fedora packages be uncontroversial raw material, and then make the hard decisions at the spin level. (I'm speaking more generally than this particular issue.)
It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora.
It doesn't work statistically: people in general don't get upset about decisions made about the desktop because they aren't using a desktop. They get upset because they *are* using a desktop and have a different vision for that detail.
It doesn't work out conceptually: you can't escape having to make decisions. If the only vision we have is how the Desktop spin works, then what policy goes into the package? Practically speaking it will be the configuration that was designed for the desktop spin, with various random changes and missing pieces where people yelled a lot on fedora-devel-list. That's not a coherent operating system. (And it's a bad basis for spins other than the Desktop spin.)
- Owen
On Thu, 2009-11-19 at 09:14 -0500, Owen Taylor wrote:
This idea comes up a lot - that we can make Fedora packages be uncontroversial raw material, and then make the hard decisions at the spin level. (I'm speaking more generally than this particular issue.)
It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora.
For the particular issue of PolicyKit policy there is no reason at all not to have the entire policy (for the entire system) in one package per spin. The design of PolicyKit 1.0 makes this really easy.
It doesn't work statistically: people in general don't get upset about decisions made about the desktop because they aren't using a desktop. They get upset because they *are* using a desktop and have a different vision for that detail.
This is one of the reasons I think policies each need to be handled centrally, each with a specific documented goal.
It doesn't work out conceptually: you can't escape having to make decisions. If the only vision we have is how the Desktop spin works, then what policy goes into the package?
The packages should ship with a "multi-user server"-type policy, i.e. a restrictive one -- this could even be set out in the packaging guidelines if need be.
Practically speaking it will be the configuration that was designed for the desktop spin, with various random changes and missing pieces where people yelled a lot on fedora-devel-list. That's not a coherent operating system. (And it's a bad basis for spins other than the Desktop spin.)
Each of the policy packages should override all of the available policy, IMHO.
Tim. */
On Thu, 2009-11-19 at 09:14 -0500, Owen Taylor wrote:
It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora.
Which is why you do it with specifically selected policy packages, and not trying to write out files in %post. Create a set of policy packages that define certain user cases, and pick from those as you construct a spin.
On Thu, Nov 19, 2009 at 4:48 PM, Jesse Keating jkeating@redhat.com wrote:
On Thu, 2009-11-19 at 09:14 -0500, Owen Taylor wrote:
It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora.
Which is why you do it with specifically selected policy packages, and not trying to write out files in %post. Â Create a set of policy packages that define certain user cases, and pick from those as you construct a spin.
This makes sense to me; but there are details to work out.
* Do we have any guidelines on what the policy should be in upstream source? Corresponding Fedora RPMs? * Do we have a fedora-default-policykit-policy? * How do we get this installed on upgrades? Code in preupgrade?
On 11/19/2009 02:49 PM, Colin Walters wrote:
- Do we have a fedora-default-policykit-policy?
Sounds like the right way to go.
- How do we get this installed on upgrades? Code in preupgrade?
"code in preupgrade" seems like a very *bad* way. Maybe "Provides: system-policykit-policy" on each of them and then make policykit itself require that, and only include one of them when doing a pungi run? I.e. the same way we do fedora-logos.
Colin Walters (walters@verbum.org) said:
Which is why you do it with specifically selected policy packages, and not trying to write out files in %post. Â Create a set of policy packages that define certain user cases, and pick from those as you construct a spin.
This makes sense to me; but there are details to work out.
- Do we have any guidelines on what the policy should be in upstream
source? Corresponding Fedora RPMs?
No, but we probably should.
- Do we have a fedora-default-policykit-policy?
polkit-desktop-policy?
- How do we get this installed on upgrades? Code in preupgrade?
In that case, it gets pulled in as a gnome-session dependency.
Bill
On Thu, 2009-11-19 at 08:48 -0800, Jesse Keating wrote:
On Thu, 2009-11-19 at 09:14 -0500, Owen Taylor wrote:
It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora.
Which is why you do it with specifically selected policy packages, and not trying to write out files in %post. Create a set of policy packages that define certain user cases, and pick from those as you construct a spin.
I can't resist pointing out the irony that the currently-under-discussion issue would precisely allow an unprivileged user to torpedo such a system of enforcement, if we were using one already =)
Once upon a time, Richard Hughes hughsient@gmail.com said:
Sure, that's not an insane idea at all. I would imagine most network admins worth their salt would be shipping custom PolicyKit overrides in F12 anyway.
If that is the Fedora expectation, then I expect a number of network admins will be choosing something other than Fedora.
2009/11/19 Chris Adams cmadams@hiwaay.net:
Once upon a time, Richard Hughes hughsient@gmail.com said:
Sure, that's not an insane idea at all. I would imagine most network admins worth their salt would be shipping custom PolicyKit overrides in F12 anyway.
If that is the Fedora expectation, then I expect a number of network admins will be choosing something other than Fedora.
If you're not shipping custom PolicyKit rules then at the moment normal users can, without authentication:
* Grant high priority scheduling to a user process * Connection sharing via a protected WiFi network * Suspend the system * Inhibit media detection * Mount a device * Restart the system * Get information about system services * Install debuginfos using abrt * Enroll new fingerprints
If you're a network administrator you should be already setting PolicyKit overrides for F10 and F11. It's basically the same for Ubuntu too. You certainly shouldn't just be doing "yum update -y" on every client machine...
Richard.
Once upon a time, Richard Hughes hughsient@gmail.com said:
If you're not shipping custom PolicyKit rules then at the moment normal users can, without authentication:
- Grant high priority scheduling to a user process
I have complained about this.
- Connection sharing via a protected WiFi network
Only if the NetworkManager daemon is running, right?
- Suspend the system
Again, on/off don't change system policy.
- Inhibit media detection
- Mount a device
The user mounts are locked down (noexec), right?
- Restart the system
Again, on/off don't change system policy.
- Get information about system services
Information that has always been available, right?
- Install debuginfos using abrt
Didn't know about this one; another thing that should be changed by default.
- Enroll new fingerprints
That's along the lines of "change their password", which is reasonable (unless this is giving elevated access to those fingerprints).
On Thu, Nov 19, 2009 at 08:31:08AM -0600, Chris Adams wrote:
Once upon a time, Richard Hughes hughsient@gmail.com said:
If you're not shipping custom PolicyKit rules then at the moment normal users can, without authentication:
- Enroll new fingerprints
That's along the lines of "change their password", which is reasonable (unless this is giving elevated access to those fingerprints).
Actually, that's a problem, because it doesn't require authentication. passwd requires that you enter your current password first, for good reason.
Chris Adams wrote:
Once upon a time, Richard Hughes hughsient@gmail.com said:
- Grant high priority scheduling to a user process
I have complained about this.
Note that RealTimeKit tries hard to prevent users from starving the CPU with such real time processes. Of course it can still be a partial DoS and you probably don't want to allow that on a machine with multiple concurrent users, but it's not a free-to-all to lock the machine up.
Kevin Kofler
On Thursday 19 November 2009 06:45:51 am Richard Hughes wrote:
2009/11/19 Rahul Sundaram sundaram@fedoraproject.org:
Right. The alternative really is defining the roles and the target audience clearly for distinct set of policies and allowing the user to trivially select it during or post-installation.
I disagree, most people will just go for the default option without understanding the subtle nuances of what they are being asked.
So the default option should be the more secure option. The PackageKit policy was a major change, and someone who was naively clicking through the installer should not be surprised by such things.
So if I pick "personal desktop", the change you made makes sense. If on the other hand, I choose "workstation" profile, I would obviously need a more locked down profile.
Surely if you're deploying a workstation (1000s of workstations?) you would just ship an extra package that set the PolicyKit policies according to the domain policy,
It is not so black and white. If I managing computers as a side favor, I may very well upgrade everyone to Fedora 12 without taking the time to look through these sorts of sweeping changes, and just do a quick test to make sure everything that used to work is still working. This is not a very uncommon situation, especially since not all Fedora users are experience at administrating systems.
The problem here is that not everyone was on board with the "single user desktop" target. I would not say it is unreasonable to miss this detail, since Fedora is periodically used as a base for RHEL, which is certainly not a single user desktop system.
The real argument is what set of users upstream software should target. There's an argument for upstream to default to "no" for all actions and for the admin to install a policy for "desktop", "workstation" etc, but then there's just the related problem of what policy package to choose by default for "Fedora".
Maybe there should just be a separate spin for "single user desktops," and it could be called "Fedora Home User Spin."
-- Ben
2009/11/19 Benjamin Kreuter ben.kreuter@gmail.com:
I would not say it is unreasonable to miss this detail, since Fedora is periodically used as a base for RHEL, which is certainly not a single user desktop system.
Sure, and RHEL default policy will most likely be different to the Desktop spin.
Richard.
On Thursday 19 November 2009 10:51:19 am Richard Hughes wrote:
2009/11/19 Benjamin Kreuter ben.kreuter@gmail.com:
I would not say it is unreasonable to miss this detail, since Fedora is periodically used as a base for RHEL, which is certainly not a single user desktop system.
Sure, and RHEL default policy will most likely be different to the Desktop spin.
I would hope so!
My point was that there are plenty of people out there who might be sticking to assumptions about *nix from a decade ago, who could be managing small groups of desktops (30 or less). I have seen this personally, and in most of those cases the root password was absolutely necessary for installing software. Allowing non-root users to install updates is just at the border of what is OK for such circumstances, but allowing ordinary users to install new packages is definitely going to far.
A number of people have suggested now that "single user desktop" be one of many options. There should at least be a "multiuser desktop" of some kind, with more restrictive policies in place, and it should not be hidden behind 3 levels of hyperlinks.
-- Ben
Dne 19.11.2009 12:15, Richard Hughes napsal(a):
The problem is who to target. If you call Fedora a desktop distro, then it makes perfect sense for local users to be able to shutdown the computer, suspend, change the system clock and install clipart without passwords, as long as it's done in a secure way.
I personally don't agree with the PK change, but I think we are missing much bigger forest for this tree. If you go to http://fedoraproject.org/get-fedora what do you see (and what most people download)?
"Get Fedora 12 Desktop Edition Now"
Where do you see "Fedora 12 Server Edition"? Nowhere, because we don't have it. I was shouting whole morning on IRC to Server Spin folks about it, but I think we are really missing Server Spin. Something which wouldn't be useful as enterprise grade server (because we don't have enough long time support for Fedora; please, don't go into this flamewar now!), but as a project to develop such beast.
And of course, it is yet another post, where I ask somebody else to do something, which I won't do :).
Matěj
On Thu, 2009-11-19 at 13:05 +0100, Matěj Cepl wrote:
Where do you see "Fedora 12 Server Edition"? Nowhere, because we don't have it. I was shouting whole morning on IRC to Server Spin folks about it, but I think we are really missing Server Spin. Something which wouldn't be useful as enterprise grade server (because we don't have enough long time support for Fedora; please, don't go into this flamewar now!), but as a project to develop such beast.
And of course, it is yet another post, where I ask somebody else to do something, which I won't do :).
We have a server spin, and it's boot.iso/netinst.iso. And no, I am not joking. Servers are installed by starting with the smallest possible package set to get the system booted and on the network, then adding the specific functionality you want the server to perform, such as http server, or mail server. Nothing more. It is the very essence of start from nothing, add what you want.
On Thu, Nov 19, 2009 at 11:42 AM, Jesse Keating jkeating@redhat.com wrote:
We have a server spin, and it's boot.iso/netinst.iso. Â And no, I am not joking. Â Servers are installed by starting with the smallest possible package set to get the system booted and on the network, then adding the specific functionality you want the server to perform, such as http server, or mail server. Â Nothing more. Â It is the very essence of start from nothing, add what you want.
...add what you want, and have PolicyKit pulled in as a dependency.
When this discussion came up I tried doing a yum erase PolicyKit on one of my systems and had it offer to remove some 372 package, including xorg-x11-drivers.
I don't mind at all that I have to type my administrator password in to do root privileged things on my desktop or laptop. I don't want the normal security model to be circumvented in odd ways.
And I really wanted a batteries-not-included server I'd install gentoo.
On Thu, 2009-11-19 at 12:33 -0500, Gregory Maxwell wrote:
...add what you want, and have PolicyKit pulled in as a dependency.
When this discussion came up I tried doing a yum erase PolicyKit on one of my systems and had it offer to remove some 372 package, including xorg-x11-drivers.
I don't mind at all that I have to type my administrator password in to do root privileged things on my desktop or laptop. I don't want the normal security model to be circumvented in odd ways.
I'm not sure what you're trying to say here. PolicyKit is an integral part of our distribution. The policies that get loaded into PolicyKit can come from different sources though, either a blanket policy package, or individual policy files to go along with individual packages. So in your case, while you have PolicyKit installed, you may not have had PackageKit, nor the policy that would grant PackageKit to do thing for local users.
On Thu, Nov 19, 2009 at 12:40 PM, Jesse Keating jkeating@redhat.com wrote:
On Thu, 2009-11-19 at 12:33 -0500, Gregory Maxwell wrote:
...add what you want, and have PolicyKit pulled in as a dependency. When this discussion came up I tried doing a yum erase PolicyKit on one of my systems and had it offer to remove some 372 package, including xorg-x11-drivers.
I'm not sure what you're trying to say here. Â PolicyKit is an integral part of our distribution. Â The policies that get loaded into PolicyKit can come from different sources though, either a blanket policy package, or individual policy files to go along with individual packages. Â So in your case, while you have PolicyKit installed, you may not have had PackageKit, nor the policy that would grant PackageKit to do thing for local users.
We obviously must be talking past each other.
I see people complaining that they don't want these non-unixy policies being silently installed on systems where they are surprising and where they are configured in invisible ways that skilled unix admins will fail to discover.
You pointed out that a server install can/should be conducted by installing a fairly limited set of packages.
I'm trying to point out that installing limited packages doesn't fix the problem because it is not clear which packages are responsible for setting (subverting, depending on your outlook) system wide security policy… except PolicyKit itself, which you can't leave out.
In the past I could simply check to see if a package contained SUID 0 binaries or modified a small number of fairly obvious system config files and have good confidence that it wasn't changing the root/user boundary line.
This takes us back to the beginning of the thread where Chris was calling for auditing, oversight, and accounting for significant security modifying behaviours.
Gregory Maxwell wrote:
In the past I could simply check to see if a package contained SUID 0 binaries or modified a small number of fairly obvious system config files and have good confidence that it wasn't changing the root/user boundary line.
The helpers which actually perform the actions authorized by PolicyKit still need to become root through some other way, PolicyKit is only used to validate that the user is authorized to use the helper.
AFAIK, there are only 3 ways the helper can get root: * SUID 0 (which you're already checking for) * running as a permanent systemwide service (you definitely need to audit those!) * D-Bus activation into the system bus: This one is new, you need to check for /usr/share/dbus-1/system-services/*.service
PolicyKit on its own doesn't escalate privileges.
Kevin Kofler
On Thu, 2009-11-19 at 11:15 +0000, Richard Hughes wrote:
2009/11/18 Chris Adams cmadams@hiwaay.net:
I would like to see this discussion separate from discussion about the current issue with PackageKit.
That would be nice :)
The problem is who to target. If you call Fedora a desktop distro, then it makes perfect sense for local users to be able to shutdown the computer, suspend, change the system clock and install clipart without passwords, as long as it's done in a secure way.
If you call Fedora a server OS, then it shouldn't be shipping PackageKit at all, and should have most of the PolicyKit authentication actions defaulting to no.
So obviously we need some middle ground. I guess if the spins "personalise" the package set then they should also personalize the security defaults. e.g. a server spin would not include PackageKit at all, and default to not letting users change the time. A desktop spin would allow the desktop user to do most things without a administrator password. The tricky part is deciding a default policy that is suitable for all the people using Fedora, which honestly, I think is impossible.
It seems to me that the way to proceed here isn't to worry about different classes of Fedora installations, but rather to think about different classes of *users*.
There may be a few machines where nobody is trusted to install signed packages without typing in the admin password again; luckily PolicyKit is a very configurable framework. But most cases, things separate pretty cleanly into:
- People who are assumed to know what they are doing (parents, the departmental IT guy, etc.)
- People who don't get to reconfigure the machine (children, students, etc.)
By having that two part policy, and having the straightforward user configuration GUI that we've been wanting for years, I think we cover almost everything. And we don't have to ask the user at install time a question that they can't answer: "do you want your machine to be safe or to be convenient?"
- Owen
2009/11/19 Owen Taylor otaylor@redhat.com:
By having that two part policy, and having the straightforward user configuration GUI that we've been wanting for years, I think we cover almost everything. And we don't have to ask the user at install time a question that they can't answer: "do you want your machine to be safe or to be convenient?"
Would this be part of the existing system-config-users tool or a new thing altogether? Are there any prototypes or mockups yet?
Richard.
On Thu, 2009-11-19 at 13:36 +0000, Richard Hughes wrote:
2009/11/19 Owen Taylor otaylor@redhat.com:
By having that two part policy, and having the straightforward user configuration GUI that we've been wanting for years, I think we cover almost everything. And we don't have to ask the user at install time a question that they can't answer: "do you want your machine to be safe or to be convenient?"
Would this be part of the existing system-config-users tool or a new thing altogether?
I think the assumption we've been making it would be working via PolicyKit rather than than consolehelper and wouldn't be called system-config-*, but that's really a detail.
The bigger deviation is the user interface; system-config-users is basically /etc/passwd in a GtkTreeView.
We'd want to introduce the idea of predefined roles. We'd want to include the head-shots shown in GDM, and otherwise make the user interface pretty and friendly. We might even want to add things like "parental control" type configuration of when certain users can use the computer.
Are there any prototypes or mockups yet?
I think we may have gotten to the mockup stage a couple of times; I seem to remember some designs that Bryan Clark did a couple of years ago, and there was another bit of work on it about a year ago. You can ask around.
The project has tended to suffer a bit from scope creep. It's pretty clear how to design a nice tool that manages local users. Personally I think that's what we should write. But once you start worrying about LDAP and frameworks for network login abstractions, then it gets much, much harder to create a pleasant experience for the simple case.
- Owen
Owen Taylor wrote:
People who are assumed to know what they are doing (parents, the departmental IT guy, etc.)
People who don't get to reconfigure the machine (children, students, etc.)
Often it's the children who know what they are doing and the parents who need their children to administer their machines from them. ;-)
Kevin Kofler
there are also inconsistencies between gui clickery and shell usage... simple example:
click "shutdown" in gnome just does it in f12
issuesing shutdown -h now on the shell asks for root password ... id really expect a system to show consistent behaviour not only in gui clickery but system wide. this feels pretty broken to me.
kind regards, Rudolf Kastl
2009/11/20 Rudolf Kastl che666@gmail.com:
there are also inconsistencies between gui clickery and shell usage... simple example:
click "shutdown" in gnome just does it in f12
issuesing shutdown -h now on the shell asks for root password ... id really expect a system to show consistent behaviour not only in gui clickery but system wide. this feels pretty broken to me.
to correct myself... it doesent directly prompt for it... but it whines that shutting down the box needs root privs... still the point is ... there are more and more inconsistencies intrudoced and that is not a good sign when it comes to security.
kind regards, rudolf kastl
On Fri, 2009-11-20 at 08:21 +0100, Rudolf Kastl wrote:
there are also inconsistencies between gui clickery and shell usage... simple example:
click "shutdown" in gnome just does it in f12
issuesing shutdown -h now on the shell asks for root password ... id really expect a system to show consistent behaviour not only in gui clickery but system wide. this feels pretty broken to me.
for extra bonus fun, try 'poweroff' :)
On Fri, 2009-11-20 at 03:42 -0500, Jeff Garzik wrote:
On 11/20/2009 02:21 AM, Rudolf Kastl wrote:
there are also inconsistencies between gui clickery and shell usage... simple example:
click "shutdown" in gnome just does it in f12
Yeah, you can do that in F11 as well :(
I agree, this needs protecting with a root password too.
Jeff this is silly. Shutdown in console by default is perfectly fine, otherwise the user can simply push the power button.
Simo.
On Fri, Nov 20, 2009 at 08:48:56 -0500, Simo Sorce ssorce@redhat.com wrote:
On Fri, 2009-11-20 at 03:42 -0500, Jeff Garzik wrote:
On 11/20/2009 02:21 AM, Rudolf Kastl wrote:
there are also inconsistencies between gui clickery and shell usage... simple example:
click "shutdown" in gnome just does it in f12
Yeah, you can do that in F11 as well :(
I agree, this needs protecting with a root password too.
Jeff this is silly. Shutdown in console by default is perfectly fine, otherwise the user can simply push the power button.
I disagree. I don't want guests accidentally shutting down machines. If they have to hit the power button it makes it a bit harder to do by mistake. It isn't a huge deal, but I'd definitely prefer that the shutdown/restart GUI stuff not work unless your authenticated as root.
On Fri, 2009-11-20 at 12:23 -0600, Bruno Wolff III wrote:
On Fri, Nov 20, 2009 at 08:48:56 -0500, Simo Sorce ssorce@redhat.com wrote:
On Fri, 2009-11-20 at 03:42 -0500, Jeff Garzik wrote:
On 11/20/2009 02:21 AM, Rudolf Kastl wrote:
there are also inconsistencies between gui clickery and shell usage... simple example:
click "shutdown" in gnome just does it in f12
Yeah, you can do that in F11 as well :(
I agree, this needs protecting with a root password too.
Jeff this is silly. Shutdown in console by default is perfectly fine, otherwise the user can simply push the power button.
I disagree. I don't want guests accidentally shutting down machines. If they have to hit the power button it makes it a bit harder to do by mistake. It isn't a huge deal, but I'd definitely prefer that the shutdown/restart GUI stuff not work unless your authenticated as root.
I understand your point, but this is really splitting hairs. In this case I think the default is fine because it is not a security issue (if you have console access). If you still don't like it you should change the default.
Now, I know that changing PolicyKit related defaults is not easy at the moment. But that's an issue of man hours, finding someone willing to build a desktop tool that allows you to easily see current policies and create local ones on the fly.
Simo.
On Friday 20 November 2009 13:30:12 Simo Sorce wrote:
On Fri, 2009-11-20 at 12:23 -0600, Bruno Wolff III wrote:
On Fri, Nov 20, 2009 at 08:48:56 -0500,
Simo Sorce ssorce@redhat.com wrote:
On Fri, 2009-11-20 at 03:42 -0500, Jeff Garzik wrote:
On 11/20/2009 02:21 AM, Rudolf Kastl wrote:
there are also inconsistencies between gui clickery and shell usage... simple example:
click "shutdown" in gnome just does it in f12
Yeah, you can do that in F11 as well :(
I agree, this needs protecting with a root password too.
Jeff this is silly. Shutdown in console by default is perfectly fine, otherwise the user can simply push the power button.
I disagree. I don't want guests accidentally shutting down machines. If they have to hit the power button it makes it a bit harder to do by mistake. It isn't a huge deal, but I'd definitely prefer that the shutdown/restart GUI stuff not work unless your authenticated as root.
I understand your point, but this is really splitting hairs. In this case I think the default is fine because it is not a security issue (if you have console access). If you still don't like it you should change the default.
+1 ... shutdown is not a security issue for a user with local console access and the same should apply to poweroff, halt, etc.
On the other hand, installing new or updated packages can be a security issue and should require additional authentication such as root's password or (perhaps) being in the wheel group or some selinux attribute.
Now, I know that changing PolicyKit related defaults is not easy at the moment. But that's an issue of man hours, finding someone willing to build a desktop tool that allows you to easily see current policies and create local ones on the fly.
If the default is changed, then an easy-to-use gui tool is need to be available to adjust / change / (perhaps) define policies at the same time that that the policy change is made.
One thing I consider really annoying are "are you sure" "popups" when some significant action (in the opinion of the developer) is done ... especially when the "popup" cannot be disabled.
Gene
On Fri, 20 Nov 2009, Simo Sorce wrote:
I agree, this needs protecting with a root password too.
Jeff this is silly. Shutdown in console by default is perfectly fine, otherwise the user can simply push the power button.
Access to the console does not imply access to the power button, or anything except the console device, really.
- James
Rudolf Kastl (che666@gmail.com) said:
there are also inconsistencies between gui clickery and shell usage... simple example:
click "shutdown" in gnome just does it in f12
issuesing shutdown -h now on the shell asks for root password ... id really expect a system to show consistent behaviour not only in gui clickery but system wide. this feels pretty broken to me.
It's a usermode bug in that there's not a wrapper for shutdown (as opposed to halt/poweroff/reboot.)
Bill
Once upon a time, Richard Hughes hughsient@gmail.com said:
The problem is who to target. If you call Fedora a desktop distro, then it makes perfect sense for local users to be able to shutdown the computer, suspend, change the system clock and install clipart without passwords, as long as it's done in a secure way.
I don't think all of that makes "perfect sense". There is a big difference between turning the system on and off and actually changing significant system settings like time and packages.
Again, you are also making the assumption that "desktop distro" == "single-user system", when the Fedora desktop work is going in the other direction (making the desktop more multi-user friendly). Many home systems are now multi-user, and not everybody should be installing software.
On 11/19/2009 09:03 AM, Chris Adams wrote:
Again, you are also making the assumption that "desktop distro" == "single-user system", when the Fedora desktop work is going in the other direction (making the desktop more multi-user friendly). Many home systems are now multi-user, and not everybody should be installing software.
+1 agreed
A huge number of comments here, in the bugzilla, and elsewhere point to "desktop spin == no root password" logic being quite unpopular.
It needs to be an /option/ in the desktop spin, an option defaulted to OFF (== prompt for root pw).
Jeff
On Thu, 2009-11-19 at 11:15 +0000, Richard Hughes wrote:
2009/11/18 Chris Adams cmadams@hiwaay.net:
I would like to see this discussion separate from discussion about the current issue with PackageKit.
That would be nice :)
The problem is who to target. If you call Fedora a desktop distro, then it makes perfect sense for local users to be able to shutdown the computer, suspend, change the system clock and install clipart without passwords, as long as it's done in a secure way.
If you call Fedora a server OS, then it shouldn't be shipping PackageKit at all, and should have most of the PolicyKit authentication actions defaulting to no.
So obviously we need some middle ground. I guess if the spins "personalise" the package set then they should also personalize the security defaults. e.g. a server spin would not include PackageKit at all, and default to not letting users change the time. A desktop spin would allow the desktop user to do most things without a administrator password. The tricky part is deciding a default policy that is suitable for all the people using Fedora, which honestly, I think is impossible.
If this is the metric then we probably need to split "Desktop" into at least 2 categories: - Personal Laptop (Netbook/etc ...) - Workstation (or multi-seat desktop, etc...)
These 2 categories have very different security requirements and implied "ownership".
Simo.
On Thu, Nov 19, 2009 at 10:58:58AM -0500, Simo Sorce wrote:
If this is the metric then we probably need to split "Desktop" into at least 2 categories:
- Personal Laptop (Netbook/etc ...)
- Workstation (or multi-seat desktop, etc...)
These 2 categories have very different security requirements and implied "ownership".
These two categories aren't at all distinct. When I let others use my netbook, it becomes a multi-user workstation.
On Thu, 2009-11-19 at 10:03 -0700, Andrew McNabb wrote:
On Thu, Nov 19, 2009 at 10:58:58AM -0500, Simo Sorce wrote:
If this is the metric then we probably need to split "Desktop" into at least 2 categories:
- Personal Laptop (Netbook/etc ...)
- Workstation (or multi-seat desktop, etc...)
These 2 categories have very different security requirements and implied "ownership".
These two categories aren't at all distinct. When I let others use my netbook, it becomes a multi-user workstation.
This is true in fact I very much prefer to have an admin group and an "unprivileged users" group. I was just replying in the context of what "Desktop" is considered.
Simo.
On Thu, 2009-11-19 at 12:38 -0500, Bill Nottingham wrote:
Simo Sorce (ssorce@redhat.com) said:
This is true in fact I very much prefer to have an admin group and an "unprivileged users" group.
I suggest you look at polkit-desktop-policy, and desktop_admin_r and desktop_user_r.
Yeah that is what I am referring to.
Simo.
On Thu, Nov 19, 2009 at 2:15 AM, Richard Hughes hughsient@gmail.com wrote:
So obviously we need some middle ground. I guess if the spins "personalise" the package set then they should also personalize the security defaults. e.g. a server spin would not include PackageKit at all, and default to not letting users change the time. A desktop spin would allow the desktop user to do most things without a administrator password. The tricky part is deciding a default policy that is suitable for all the people using Fedora, which honestly, I think is impossible.
Can we decide on the security defaults that act as a backstop to spin personalizations? My personal preference would be to have a default proto-policy that was as hardened as conceivably possible in the packages themselves and then each spin concept makes deliberate changes to soften the security stance by writing local policy in their kickstart files actions.
That would make each change that softens the security posture a deliberate change that is easily reviewed by reading over the kickstart files. This stills allows for a desktop spin to have a security stance different from that of a server spin... as an initial install target ... but should avoid unexpected behavior across update boundaries or in real world situations that don't fit the designed for usage case.
-jef
Am 2009-11-19 00:58, schrieb Chris Adams:
After seeing two conflicts over PolicyKit default policies allowing unprivileged to do things that previously only root could do, it seems to me that there needs to be some kind of oversight on security policy for the distribution. Right now, any package maintainer can make changes to system security policy, without announcing it, getting any approval, etc.
In the two cases I've seen, the maintainers decided that their way was the right way and closed the bug reports without any real discussion, which just seems unacceptable to me.
Any package (whether new or an update) that adds/changes PolicyKit, consolehelper, or PAM configuration, and anything that installs new setuid/setgid executables, should require some additional third-party review. Any significant changes that passes review should require some minimum amount of advance notice and documentation on how to revert (preferably in some common easy-to-find place in the wiki).
Is this feasible? Who needs to look at this?
I would like to see this discussion separate from discussion about the current issue with PackageKit.
I would like to see (and I brought this up on the list before) a page listing selinux exceptions. That is: applications which are essentially untrusted because of weird things they do with memory or whatever. The list would be in two parts: apps that have to be like this because of how they work (e.g. Java, mono) and apps that are badly written and should be fixed (firefox was/is one culprit).
The list would ensure two things: 1. That there is visibility of what selinux does not cover 2. That bad applications get attention or at least exposure