If you would have a Linux system where in a default configuration everybody with a desktop session would be able to modify at will such "insignificant" system settings like values of a hardware clock and a system clock, not mentioning such details like global changes to a configured timezone, then would you think that this is: - how it should be - a minor boo-boo - somewhat troublesome - or a really serious problem of a system integrity with security consequence too (messed up logs but not only)?
Now knowing that various programs will be seriously affected by sudden changes in clock various, and ntpd is very careful when doing clock adjustments, would you think that the situation described in the previous paragraph is something which does not happen on Fedora or maybe it does?
Michal
On Mon, 2009-02-23 at 09:47 -0700, Michal Jaegermann wrote:
If you would have a Linux system where in a default configuration everybody with a desktop session would be able to modify at will such "insignificant" system settings like values of a hardware clock and a system clock, not mentioning such details like global changes to a configured timezone, then would you think that this is:
- how it should be
- a minor boo-boo
- somewhat troublesome
- or a really serious problem of a system integrity with security consequence too (messed up logs but not only)?
Now knowing that various programs will be seriously affected by sudden changes in clock various, and ntpd is very careful when doing clock adjustments, would you think that the situation described in the previous paragraph is something which does not happen on Fedora or maybe it does?
Are you reporting a bug? AFAIK changes to the system clock require the root password, as do changes to the global timezone. Has this changed in F11?
poc
On Mon, Feb 23, 2009 at 02:09:57PM -0430, Patrick O'Callaghan wrote:
On Mon, 2009-02-23 at 09:47 -0700, Michal Jaegermann wrote:
Now knowing that various programs will be seriously affected by sudden changes in clock various, and ntpd is very careful when doing clock adjustments, would you think that the situation described in the previous paragraph is something which does not happen on Fedora or maybe it does?
Are you reporting a bug?
That is the next part of the riddle. How long time ago this issue was reported?
AFAIK changes to the system clock require the root password, as do changes to the global timezone.
I thought so too but this is not the case. You are correct if you are trying to modify these values through 'System->Administration->Date&Time' but this is not the only way to do it and you need only your password for the first time and no password at all after that once you are on a desktop.
Has this changed in F11?
No, this did not change in F11. The problem goes way back.
Michal
It looks like what short of authentication is required to change the system clock is now configurable in System -> Preferences -> Authorizations.
-B.
On Mon, 2009-02-23 at 15:13 -0500, Christopher Beland wrote:
It looks like what short of authentication is required to change the system clock is now configurable in System -> Preferences -> Authorizations.
Otherwise Known As...Policykit.
On Mon, Feb 23, 2009 at 03:13:02PM -0500, Christopher Beland wrote:
It looks like what short of authentication is required to change the system clock is now configurable in System -> Preferences -> Authorizations.
It is not a question how to change authorizations but that default authorizations, i.e. what you will get on just installed system, are seriously backwards defaulting to a security disaster. Yes, you can fix that using polkit-action, if you noticed that something is amiss, but I wonder on how many installed systems this was actually done and what else is lurking there.
The issue was reported at least on 2008-06-06 as https://bugzilla.redhat.com/show_bug.cgi?id=450304
Michal
On Mon, 2009-02-23 at 12:32 -0700, Michal Jaegermann wrote:
On Mon, Feb 23, 2009 at 02:09:57PM -0430, Patrick O'Callaghan wrote:
On Mon, 2009-02-23 at 09:47 -0700, Michal Jaegermann wrote:
Now knowing that various programs will be seriously affected by sudden changes in clock various, and ntpd is very careful when doing clock adjustments, would you think that the situation described in the previous paragraph is something which does not happen on Fedora or maybe it does?
Are you reporting a bug?
That is the next part of the riddle. How long time ago this issue was reported?
Why don't you simply state what you're talking about instead of asking riddles?
AFAIK changes to the system clock require the root password, as do changes to the global timezone.
I thought so too but this is not the case. You are correct if you are trying to modify these values through 'System->Administration->Date&Time' but this is not the only way to do it and you need only your password for the first time and no password at all after that once you are on a desktop.
So this has something to do with Gnome. You didn't say that. The KDE clock applet doesn't allow you to change the time (just the timezone) and the Settings dialogue requires the root password. If the Gnome clock applet does allow this without a root password then clearly it's broken in Fedora. Could it be contamination from the Ubuntu model?
Has this changed in F11?
No, this did not change in F11. The problem goes way back.
In that case it might make more sense to discuss it on the Fedora list and not here.
poc
On Mon, Feb 23, 2009 at 05:10:41PM -0430, Patrick O'Callaghan wrote:
Why don't you simply state what you're talking about instead of asking riddles?
I stated: "Anybody with a desktop session can mess with a system clock at will. No root password or anything of that sort required". I was curious if other people think that this is as serious as I know it is.
So this has something to do with Gnome.
Not really. Rather with PolicyKit and broken defaults.
The KDE clock applet doesn't allow you to change the time (just the timezone)
If that is a global change, and not how time is displayed on this specific desktop, that this is bad enough. Most timestamps in system logs are in local time with no zone indication. Besides not much prevents you to login into a different type of a sessions and I asked this: if you can modify clocks as you please then do you think that this is insignificant, minor hiccup or really bad. I am still interested in answers.
Could it be contamination from the Ubuntu model?
That appears to be a contamination with "one-user-system" mindset.
In that case it might make more sense to discuss it on the Fedora list and not here.
Not much really to discuss. A bug was filed a while ago and it just sits there.
Michal
Once upon a time, Michal Jaegermann michal@harddata.com said:
On Mon, Feb 23, 2009 at 05:10:41PM -0430, Patrick O'Callaghan wrote:
Why don't you simply state what you're talking about instead of asking riddles?
I stated: "Anybody with a desktop session can mess with a system clock at will. No root password or anything of that sort required". I was curious if other people think that this is as serious as I know it is.
You've left it as a riddle as to how it would be done, as nobody else can reproduce what you claim. Without concrete details, you'll get quicksand responses.
On Mon, 2009-02-23 at 16:30 -0600, Chris Adams wrote:
Once upon a time, Michal Jaegermann michal@harddata.com said:
On Mon, Feb 23, 2009 at 05:10:41PM -0430, Patrick O'Callaghan wrote:
Why don't you simply state what you're talking about instead of asking riddles?
I stated: "Anybody with a desktop session can mess with a system clock at will. No root password or anything of that sort required". I was curious if other people think that this is as serious as I know it is.
You've left it as a riddle as to how it would be done, as nobody else can reproduce what you claim. Without concrete details, you'll get quicksand responses.
Erm. I reproduced it.
On Mon, Feb 23, 2009 at 5:30 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Michal Jaegermann michal@harddata.com said:
On Mon, Feb 23, 2009 at 05:10:41PM -0430, Patrick O'Callaghan wrote:
Why don't you simply state what you're talking about instead of asking riddles?
I stated: "Anybody with a desktop session can mess with a system clock at will. No root password or anything of that sort required". I was curious if other people think that this is as serious as I know it is.
You've left it as a riddle as to how it would be done, as nobody else can reproduce what you claim. Without concrete details, you'll get quicksand responses.
Easily reproduced it here on a fresh F10 install where the user account had never been subjected to the root password:
Right click the gnome clock applet, adjust date & time. It asks for a password, the *user* password satisfies it. I never would have caught this: My time is always set via NTP, and if I ever accidentally clicked my way to that dialog I would have assumed that it wanted the root password.
This shouldn't have been sent to this list: It should have been filed as a confidential bug, it's CERT announcement material. I guess its too late now.
A non-privileged "kick NTP" command is probably acceptable. An adjustment of the per-user TZ variable is completely safe. A non-privileged change-system-timezone *might* be safe, but that is still a major change in the Unix security model so determining the safety would take extensive analysis and discussion. It would probably be better to transition to a model where the system timezone was always UTC, and applications heeded a per-user timezone.
…but allowing regular users to simply adjust the time arbitrarily is an absolute security disaster.
On Tuesday 24 February 2009 01:40:40 am Gregory Maxwell wrote:
This shouldn't have been sent to this list: It should have been filed as a confidential bug, it's CERT announcement material. I guess its too late now.
Yes, I think so, too. From a security PoV, this creates a big problem in log correlation. An attacker can create a misleading audit trail that might make something look like it happened at one time while it really happened at another. You also have time based authentications that could allow access at disallowed times, and you can also prevent cron jobs from running that perhaps would have found an intrusion.
A bug should be filed and this should be fixed in all affected releases ASAP.
-Steve
On Tue, Feb 24, 2009 at 08:42:56AM -0500, Steve Grubb wrote:
On Tuesday 24 February 2009 01:40:40 am Gregory Maxwell wrote:
This shouldn't have been sent to this list: It should have been filed as a confidential bug, it's CERT announcement material. I guess its too late now.
Yes, I think so, too. From a security PoV, this creates a big problem in log correlation.
This is public as https://bugzilla.redhat.com/show_bug.cgi?id=450304 for close to nine months now.
A bug should be filed and this should be fixed in all affected releases ASAP.
The bug _was_ filed. Anybody pays attention?
Michal
On Tue, Feb 24, 2009 at 10:47:57AM -0700, Michal Jaegermann wrote:
On Tue, Feb 24, 2009 at 08:42:56AM -0500, Steve Grubb wrote:
On Tuesday 24 February 2009 01:40:40 am Gregory Maxwell wrote:
This shouldn't have been sent to this list: It should have been filed as a confidential bug, it's CERT announcement material. I guess its too late now.
Yes, I think so, too. From a security PoV, this creates a big problem in log correlation.
This is public as https://bugzilla.redhat.com/show_bug.cgi?id=450304 for close to nine months now.
BTW - defaults are really trivial to fix and it is very easy to repair that on any particular system. The problem is, of course, that now you have to check every single one and changing defaults with a help of polkit-action does not automatically revoke already self-granted priviledges. The next headache.
Michal
Once upon a time, Gregory Maxwell gmaxwell@gmail.com said:
Right click the gnome clock applet, adjust date & time. It asks for a password, the *user* password satisfies it. I never would have caught this: My time is always set via NTP, and if I ever accidentally clicked my way to that dialog I would have assumed that it wanted the root password.
The question is: what path is this taking to get the required access level (I guess PolicyKit)? What other things may be available this way (is there any limit)? How was this audited before being added to Fedora?
There is a bug about this in RH BZ (450304) that has been open since 2008-06-06 with basically no action.
What mechanism is there to keep track of these policies? There should be a Fedora policy to control RPMs adding new policies to PolicyKit. As a system admin, I look for setuid/setgid binaries and open sockets, but now there's a new method to bypass that for root-level access.
I admit, I haven't paid much attention to PolicyKit (I'm more of a server guy; I run Fedora on my desktop just because). I see it is pretty deeply intertwined; "yum remove PolicyKit" wants to remove 214 packages.
Once upon a time, Chris Adams cmadams@hiwaay.net said:
What mechanism is there to keep track of these policies? There should be a Fedora policy to control RPMs adding new policies to PolicyKit. As a system admin, I look for setuid/setgid binaries and open sockets, but now there's a new method to bypass that for root-level access.
As a follow-up, I see on F10 that a user can also increase their process priority level (which is normally a privilege reserved for root). This is often useful in timing attacks and should not be allowed.
If I'm reading the policy right, users can change PackageKit proxy settings and force a refresh of metadata. How much has PackageKit's (and yum's) code been audited for security? If I can point it at a proxy and force it to download data, how secure is it against attack (e.g. via corrupted data)?
On Tue, 2009-02-24 at 08:18 -0600, Chris Adams wrote:
Once upon a time, Chris Adams cmadams@hiwaay.net said:
What mechanism is there to keep track of these policies? There should be a Fedora policy to control RPMs adding new policies to PolicyKit. As a system admin, I look for setuid/setgid binaries and open sockets, but now there's a new method to bypass that for root-level access.
As a follow-up, I see on F10 that a user can also increase their process priority level (which is normally a privilege reserved for root). This is often useful in timing attacks and should not be allowed.
If I'm reading the policy right, users can change PackageKit proxy settings and force a refresh of metadata. How much has PackageKit's (and yum's) code been audited for security? If I can point it at a proxy and force it to download data, how secure is it against attack (e.g. via corrupted data)?
Can we please try to stay realistic here. We are talking about default settings for a desktop system, where users are expected to be able to update their systems.
Once upon a time, Matthias Clasen mclasen@redhat.com said:
On Tue, 2009-02-24 at 08:18 -0600, Chris Adams wrote:
If I'm reading the policy right, users can change PackageKit proxy settings and force a refresh of metadata. How much has PackageKit's (and yum's) code been audited for security? If I can point it at a proxy and force it to download data, how secure is it against attack (e.g. via corrupted data)?
Can we please try to stay realistic here. We are talking about default settings for a desktop system, where users are expected to be able to update their systems.
What is unrealistic about possible security attacks on the system?
Actually updating the system requires root access; why do changing the proxy server and refreshing metadata not?
On Tue, Feb 24, 2009 at 9:50 AM, Matthias Clasen mclasen@redhat.com wrote:
On Tue, 2009-02-24 at 08:18 -0600, Chris Adams wrote:
Once upon a time, Chris Adams cmadams@hiwaay.net said:
What mechanism is there to keep track of these policies? There should be a Fedora policy to control RPMs adding new policies to PolicyKit. As a system admin, I look for setuid/setgid binaries and open sockets, but now there's a new method to bypass that for root-level access.
As a follow-up, I see on F10 that a user can also increase their process priority level (which is normally a privilege reserved for root). This is often useful in timing attacks and should not be allowed.
If I'm reading the policy right, users can change PackageKit proxy settings and force a refresh of metadata. How much has PackageKit's (and yum's) code been audited for security? If I can point it at a proxy and force it to download data, how secure is it against attack (e.g. via corrupted data)?
Can we please try to stay realistic here. We are talking about default settings for a desktop system, where users are expected to be able to update their systems.
Chris' proposed attack pattern is not so different from being able to LD_PRELOAD ahead of running a SUID binary.
I find it somewhat amusing that so much work was done to eliminate extraneous SUID binaries in the system but then policykit was added which carries with it the risk of parallel classes of security vulnerabilities. Policykit is a neat and useful feature, but it needs to be treated with the same strict scrutiny that other SUID mechanisms are. The current default security settings for time are a sign that important things were overlooked.
On Tue, Feb 24, 2009 at 08:10:07AM -0600, Chris Adams wrote:
The question is: what path is this taking to get the required access level (I guess PolicyKit)? What other things may be available this way (is there any limit)? How was this audited before being added to Fedora?
There is a bug about this in RH BZ (450304) that has been open since 2008-06-06 with basically no action.
Here is a script which allows to check and override defaults in question:
#!/bin/sh
# Change insane defaults for messing with system clock. # To grant/revoke some particular action to a given user use polkit-auth
if [ "$1" ] ; then show=yes fi
actions=" org.gnome.clockapplet.mechanism.settimezone org.gnome.clockapplet.mechanism.settime org.gnome.clockapplet.mechanism.configurehwclock "
if [ "$show" = yes ] ; then for act in $actions ; do polkit-action --action $act done else for act in $actions ; do polkit-action --set-defaults-active $act auth_admin_keep_session done fi
If you want there 'auth_admin_keep_session' or something else (see 'man polkit-action' for possibilities) that is up to you.
What mechanism is there to keep track of these policies?
No idea; but apparently it does not work too well. I did not try so far to audit what are defaults for anything which shows up when you type 'polkit-action'. Quite likely I should.
Michal
On Mon, 2009-02-23 at 15:25 -0700, Michal Jaegermann wrote:
[...]> The KDE
clock applet doesn't allow you to change the time (just the timezone)
If that is a global change, and not how time is displayed on this specific desktop, that this is bad enough.
It isn't. It affects the displayed time on the desktop. The system's view of the timezone does not change.
Most timestamps in system logs are in local time with no zone indication. Besides not much prevents you to login into a different type of a sessions and I asked this: if you can modify clocks as you please then do you think that this is insignificant, minor hiccup or really bad. I am still interested in answers.
AFAIK you can only change the system timezone via the root password. Again, this is KDE. I've no idea what Gnome does. Obviously if it allows a change like this without authentication then it's broken, but of course it wouldn't be able to do it if the system didn't let it.
poc
On Tue, 2009-02-24 at 10:48 -0430, Patrick O'Callaghan wrote:
AFAIK you can only change the system timezone via the root password. Again, this is KDE. I've no idea what Gnome does. Obviously if it allows a change like this without authentication then it's broken, but of course it wouldn't be able to do it if the system didn't let it.
GNOME is doing it the 'right way' by devolving authentication to PolicyKit; this is the model for PK usage. The problem here is the default policy in PK. Presumably whoever wrote it thought that maliciously changing the system clock couldn't cause any problems. I'd love to know who that was...
On Tue, Feb 24, 2009 at 10:48:12AM -0430, Patrick O'Callaghan wrote:
On Mon, 2009-02-23 at 15:25 -0700, Michal Jaegermann wrote:
[...]> The KDE
clock applet doesn't allow you to change the time (just the timezone)
If that is a global change, and not how time is displayed on this specific desktop, that this is bad enough.
It isn't. It affects the displayed time on the desktop. The system's view of the timezone does not change.
Yes, I was quite sure this only this could and should happen if you will switch timezone in clockapplet (a very poor cousin of that would a modification only for a time displayed by _that_ clock). I was quite surprised when I found out that /etc/localtime changed.
AFAIK you can only change the system timezone via the root password.
Not quite if you can start on your system a Gnome desktop session and you have 'gnome-panel' package installed. That provides /usr/libexec/clock-applet. Log out from a KDE session, change a session type, login into a Gnome desktop, proceed like above ...
Michal
On Tue, 2009-02-24 at 11:38 -0700, Michal Jaegermann wrote:
On Tue, Feb 24, 2009 at 10:48:12AM -0430, Patrick O'Callaghan wrote:
On Mon, 2009-02-23 at 15:25 -0700, Michal Jaegermann wrote:
[...]> The KDE
clock applet doesn't allow you to change the time (just the timezone)
If that is a global change, and not how time is displayed on this specific desktop, that this is bad enough.
It isn't. It affects the displayed time on the desktop. The system's view of the timezone does not change.
Yes, I was quite sure this only this could and should happen if you will switch timezone in clockapplet (a very poor cousin of that would a modification only for a time displayed by _that_ clock). I was quite surprised when I found out that /etc/localtime changed.
Once again, under KDE it doesn't. I now understand your point, that PK is wrong and should be fixed. What confused me is that you started this whole thread without saying that the vulnerability manifests through Gnome.
AFAIK you can only change the system timezone via the root password.
Not quite if you can start on your system a Gnome desktop session and you have 'gnome-panel' package installed. That provides /usr/libexec/clock-applet. Log out from a KDE session, change a session type, login into a Gnome desktop, proceed like above ...
See above.
poc
On Mon, Feb 23, 2009 at 2:32 PM, Michal Jaegermann michal@harddata.com wrote:
I thought so too but this is not the case. You are correct if you are trying to modify these values through 'System->Administration->Date&Time' but this is not the only way to do it and you need only your password for the first time and no password at all after that once you are on a desktop.
Has this changed in F11?
No, this did not change in F11. The problem goes way back.
I'm not sure what's going on with your system, but on mine (F-10), when I actually try to set the time, I am prompted for the administrator password. The default PolicyKit policies are working fine here.
Have you tried replicating this on a fresh user account?
On Mon, 2009-02-23 at 17:04 -0500, Michel Salim wrote:
On Mon, Feb 23, 2009 at 2:32 PM, Michal Jaegermann michal@harddata.com wrote:
I thought so too but this is not the case. You are correct if you are trying to modify these values through 'System->Administration->Date&Time' but this is not the only way to do it and you need only your password for the first time and no password at all after that once you are on a desktop.
Has this changed in F11?
No, this did not change in F11. The problem goes way back.
I'm not sure what's going on with your system, but on mine (F-10), when I actually try to set the time, I am prompted for the administrator password. The default PolicyKit policies are working fine here.
Have you tried replicating this on a fresh user account?
For me (system is F10, updated to current Rawhide) it asks for user password.
On Mon, Feb 23, 2009 at 02:13:03PM -0800, Adam Williamson wrote:
For me (system is F10, updated to current Rawhide) it asks for user password.
Again, what
for a in settimezone settime configurehwclock ; do polkit-action --action org.gnome.clockapplet.mechanism.$a done
has to say?
Due to a default "auth_self_keep_always" once you allowed yourself such changes modyfing defaults will not remove those authorizations. 'polkit-auth' should be used although you can likely just remove newly created files from /var/lib/PolicyKit/.
Micha;
On Mon, 2009-02-23 at 15:57 -0700, Michal Jaegermann wrote:
On Mon, Feb 23, 2009 at 02:13:03PM -0800, Adam Williamson wrote:
For me (system is F10, updated to current Rawhide) it asks for user password.
Again, what
for a in settimezone settime configurehwclock ; do polkit-action --action org.gnome.clockapplet.mechanism.$a done
has to say?
Due to a default "auth_self_keep_always" once you allowed yourself such changes modyfing defaults will not remove those authorizations. 'polkit-auth' should be used although you can likely just remove newly created files from /var/lib/PolicyKit/.
What exactly are we trying to establish here ? Is that another riddle ? If you want to know the default policies, just open /usr/share/PolicyKit/policy/org.gnome.clockapplet.mechanism.policy and you will find that it is indeed
<allow_inactive>no</allow_inactive> <allow_active>auth_self_keep_always</allow_active>
On Mon, Feb 23, 2009 at 06:08:44PM -0500, Matthias Clasen wrote:
On Mon, 2009-02-23 at 15:57 -0700, Michal Jaegermann wrote:
On Mon, Feb 23, 2009 at 02:13:03PM -0800, Adam Williamson wrote:
For me (system is F10, updated to current Rawhide) it asks for user password.
Once. And not the next time. There is this "keep_always".
What exactly are we trying to establish here ? Is that another riddle ?
No, I misread the above in a hurry.
If you want to know the default policies, just open /usr/share/PolicyKit/policy/org.gnome.clockapplet.mechanism.policy and you will find that it is indeed
<allow_inactive>no</allow_inactive> <allow_active>auth_self_keep_always</allow_active>
That can be modified through 'polkit-action --set-defaults-active ...' so this loop I have shown will print then something else.
Michal
Michal Jaegermann wrote:
On Mon, Feb 23, 2009 at 06:08:44PM -0500, Matthias Clasen wrote:
On Mon, 2009-02-23 at 15:57 -0700, Michal Jaegermann wrote:
On Mon, Feb 23, 2009 at 02:13:03PM -0800, Adam Williamson wrote:
For me (system is F10, updated to current Rawhide) it asks for user password.
Once. And not the next time. There is this "keep_always".
What exactly are we trying to establish here ? Is that another riddle ?
No, I misread the above in a hurry.
If you want to know the default policies, just open /usr/share/PolicyKit/policy/org.gnome.clockapplet.mechanism.policy and you will find that it is indeed
<allow_inactive>no</allow_inactive> <allow_active>auth_self_keep_always</allow_active>
That can be modified through 'polkit-action --set-defaults-active ...' so this loop I have shown will print then something else.
I think Dan Walsh tried to address these PolicyKit defaults on the fedora-security-list last November:
"PolicyKit Proliferation is a Security Disaster in the making" http://www.redhat.com/archives/fedora-security-list/2008-November/msg00000.h...
On Mon, Feb 23, 2009 at 6:19 PM, Michal Jaegermann michal@harddata.com wrote:
On Mon, Feb 23, 2009 at 06:08:44PM -0500, Matthias Clasen wrote:
On Mon, 2009-02-23 at 15:57 -0700, Michal Jaegermann wrote:
On Mon, Feb 23, 2009 at 02:13:03PM -0800, Adam Williamson wrote:
For me (system is F10, updated to current Rawhide) it asks for user password.
Once. And not the next time. There is this "keep_always".
You have a valid security concern, but expressing it in a riddle -- does it not smack a bit of "security by obscurity"? It does not help anyone, though it seems to gain you some attention, at least.
Reading your initial posts, until you gave us specifics, it sounded as if you said "these actions do not need authentication!" rather than "your authorizations persist forever by default". The former is a security hole, the latter is not as bad -- it's a bad default, arguably.
I actually like OS X's control panel. It tells you, when viewing any settings, which action is currently unlocked (authorized) and which ones are not. We have System->Prefs->System->Auths in GNOME (and the equivalent in KDE), but that's another place to look, it's not as intuitive.
On Mon, 2009-02-23 at 15:57 -0700, Michal Jaegermann wrote:
Due to a default "auth_self_keep_always" once you allowed yourself such changes modyfing defaults will not remove those authorizations.
I'm not sure what you're saying (I have a very limited knowledge of PolicyKit), but it appears to be "once you lower security for the clock functions -- using the root password of course -- it stays lowered". Is that correct?
If so, in what way is this more serious than, say, removing the root password entirely? I'm not trying to be confrontational, it's just that so far you haven't really explained your point.
poc
On Tue, Feb 24, 2009 at 10:08 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2009-02-23 at 15:57 -0700, Michal Jaegermann wrote:
Due to a default "auth_self_keep_always" once you allowed yourself such changes modyfing defaults will not remove those authorizations.
I'm not sure what you're saying (I have a very limited knowledge of PolicyKit), but it appears to be "once you lower security for the clock functions -- using the root password of course -- it stays lowered". Is that correct?
If so, in what way is this more serious than, say, removing the root password entirely? I'm not trying to be confrontational, it's just that so far you haven't really explained your point.
Not using the root password. Using your own user account password.
If the root password were involved, caching it by default would be a poor practice worthy of repair, but not a vulnerability. But it is not involved as far as I can tell. The current settings allow random users to change the system time without any administrative credentials. It's basically equivalent to giving clock the suid bit.
The "ask for the users password; then remember it" behaviour is weird. Should the system ever be doing that? I can see cases where you might want to prove that requested action is, in fact, on behalf of the user… but if the authentication is kept that use case is defeated, so I'm not sure what purpose it serves other than to level people with the mistaken impression that the root password is required as would be proper.
On Tue, 2009-02-24 at 10:25 -0500, Gregory Maxwell wrote:
The "ask for the users password; then remember it" behaviour is weird. Should the system ever be doing that?
Yeah, the 'keep always' part is one of the weakest points of the current polkit design. That is why it'll be purged from the next version of PolicyKit.
Matthias
On Mon, Feb 23, 2009 at 05:04:51PM -0500, Michel Salim wrote:
On Mon, Feb 23, 2009 at 2:32 PM, Michal Jaegermann michal@harddata.com wrote:
I thought so too but this is not the case. You are correct if you are trying to modify these values through 'System->Administration->Date&Time' but this is not the only way to do it and you need only your password for the first time and no password at all after that once you are on a desktop.
Has this changed in F11?
No, this did not change in F11. The problem goes way back.
I'm not sure what's going on with your system, but on mine (F-10), when I actually try to set the time, I am prompted for the administrator password.
How you are trying to set time? As I wrote above - if through 'System->Administration->Date&Time' than _that_ will ask you for a root password. But it turns out that this is not the only way you can set clock from your desktop.
The default PolicyKit policies are working fine here.
Could you, please, post an output from the following shell script:
for a in settimezone settime configurehwclock ; do polkit-action --action org.gnome.clockapplet.mechanism.$a done
The only interesting parts are really default_active. If that says "auth_self_keep_always", which is a "factory default", then you do need a root password for these changes but you have to do them differently than you tried.
I guess that I should walk through the whole output of 'polkit-action' and see what else interesting I can find there.
Michal
On Mon, 2009-02-23 at 15:47 -0700, Michal Jaegermann wrote:
for a in settimezone settime configurehwclock ; do polkit-action --action org.gnome.clockapplet.mechanism.$a done
The only interesting parts are really default_active. If that says "auth_self_keep_always", which is a "factory default", then you do need a root password for these changes but you have to do them differently than you tried.
Since you asked:
# for a in settimezone settime configurehwclock ; do
polkit-action --action org.gnome.clockapplet.mechanism.$adone
action_id: org.gnome.clockapplet.mechanism.settimezone description: Change system time zone message: Privileges are required to change the system time zone. default_any: no default_inactive: no default_active: auth_self_keep_always action_id: org.gnome.clockapplet.mechanism.settime description: Change system time message: Privileges are required to change the system time. default_any: no default_inactive: no default_active: auth_self_keep_always action_id: org.gnome.clockapplet.mechanism.configurehwclock description: Configure hardware clock message: Privileges are required to configure the hardware clock. default_any: no default_inactive: no default_active: auth_self_keep_always
poc
On Tue, Feb 24, 2009 at 10:33:46AM -0430, Patrick O'Callaghan wrote:
On Mon, 2009-02-23 at 15:47 -0700, Michal Jaegermann wrote:
for a in settimezone settime configurehwclock ; do polkit-action --action org.gnome.clockapplet.mechanism.$a done
The only interesting parts are really default_active. If that says "auth_self_keep_always", which is a "factory default", then you do need a root password for these changes but you have to do them differently than you tried.
Since you asked:
...
default_active: auth_self_keep_always
^^^^^^^^^^
So here is your answer. Using clockapplet to do all actions in question you have to authenticate yourself, with your password and not root, _only once_ for a lifetime of your installation (unless root will explicitely revoke those priviledges).
Michal
On Mon, 2009-02-23 at 15:47 -0700, Michal Jaegermann wrote:
How you are trying to set time? As I wrote above - if through 'System->Administration->Date&Time' than _that_ will ask you for a root password. But it turns out that this is not the only way you can set clock from your desktop.
BTW, the reason for the difference is that doing it that way uses the old consolehelper system, not PolicyKit.
Some of you raised objections that I am talking about the issue on fedora-test-list and not on some closed security lists or through CVE. If somebody want to pursue those avenues then be my guest. In the meatime David Zeuthen decreed that 'all these "security" concerns are completely bullshit'. See for yourself here: https://bugzilla.redhat.com/show_bug.cgi?id=450304#c7 Unfortunately he "owns" that bug. That pronouncement from him is totally unsurprising as in the past he demonstrated such "deep understanding" already many times.
In any case I am out of here and from me no further comments.
Michal
On Thursday 19 March 2009 18:31:42 Michal Jaegermann wrote:
Some of you raised objections that I am talking about the issue on fedora-test-list and not on some closed security lists or through CVE. If somebody want to pursue those avenues then be my guest. In the meatime David Zeuthen decreed that 'all these "security" concerns are completely bullshit'. See for yourself here: https://bugzilla.redhat.com/show_bug.cgi?id=450304#c7 Unfortunately he "owns" that bug. That pronouncement from him is totally unsurprising as in the past he demonstrated such "deep understanding" already many times.
Did you have to quote that completely out of context?
-
Adam Williamson -
Bill Crawford -
Chris Adams -
Christopher Beland -
Gregory Maxwell -
Matthias Clasen -
Michal Jaegermann -
Michel Salim -
Patrick O'Callaghan -
Steve Grubb -
Todd Zullinger