Hi all,

IMHO, the save password dialog was always confusing (didn't say for how long it would save) and it a pretty big security liability. For me it is better to keep asking the password for everything that is admin related - no exceptions.

Best regards, Tiago

On Wed, Nov 30, 2011 at 7:10 AM, Darrell Anderson humanreadable@yahoo.comwrote:

...

...

I submitted a patch to bug

report 388

...

(http://bugs.pearsoncomputing.net/show_bug.cgi?id=388).

The patch restores

...

the visibility of the kdesu "Keep password" check box.

In TDE, the check

...

box is hard-coded invisible rather than being a

function of the kdesu -t

...

parameter as in 3.5.10.

The patch (kdebase/kdesu/kdesu/kdesu.cpp):

================================================ // Try to exec the command with

kdesud.

...

 bool keep = !args->isSet("n")

&& have_daemon;

...

• bool terminal = true;

• bool terminal = args->isSet("t"); bool new_dcop =

args->isSet("newdcop");

...

 bool withIgnoreButton =

args->isSet("ignorebutton");

...

================================================

Although I suspect many will welcome the patch, there

likely will be just

...

as many who will fear being eaten in the dark by grues

if this check box

...

is visible.

I dislike the idea of those who want this check box

visible to have to

...

always patch the TDE sources in their build scripts.

Is there a way to test who wants this check box

visible and those who

...

don't so no build-time patching is required and

everybody is happy?

...

I think the 'buntu family of distros don't use kdesu

and instead use

...

kdesudo. Perhaps this patch does not affect those

distros. If that is the

...

case then the discussion falls on everybody else.

Ideas?

The problem is that AFAIK there is no way to *unset* the password once it is stored. Possibly a better idea would be to file an enhancement bug report for a kcontrol module to reset the stored password, and then block 388 on that new bug report. Also we should add a brief dialog when the password is stored for the first time letting the user know where to go to unset the stored password.

Perhaps the code set has changed in TDE from 3.5.10. If I understand correctly kdesu in 3.5.10 worked like this:

• The password is not recorded in any config file anywhere. The password

is maintained in memory.

• The password is good only for that session. Exiting TDE kills all kdesu

hooks. If running with a graphical login that would be exiting TDE to the login manager. If running X from the command line that would be exiting X back to the command line. Logging out at the command line is not necessary --- only exiting the TDE session.

• If the check box is not enabled, the password is forgotten immediately.

This is easily tested by closing the app and immediately running kdesu to run the same app. The password is again required.

• If the check box is enabled, the password is remembered only for the

period set in $PREFIX/include/kdesu/defaults.h and ONLY for that app. I think the default is 2 hours. This is testable by waiting for the default time out period and then again launching kdesu for that app. A password is again required.

• If kdesu is launched for a different app, then repeat the previous

steps. Passwords stored in memory for one app do not grant access to other apps.

Is the check box a potential security risk? That kind of question always opens the proverbial can of worms because the only way to start protecting a computer is to use in a locked room with no services running at all. :) Nonetheless, the time out period does pose a potential risk. Even if an admin closes a kdesu app, another person could restart the app if the timeout period has not expired. A safe policy is to not enable the check box in those environments or to use the TDE screen lockdown. Some people might then argue to just eliminate the check box, but not everybody works in that environment. The check box should be available to those who want the feature. For example, I work at home and have no cats to walk on my keyboard. :)

The administrator's section of KControl would be a good location to configure whether to show the check box. From the command line or konsole, running kdesu -n will open the dialog box without the check box. Disabling the check box through KControl would have the effect of setting the kdesu default to use the -n parameter. The setting could be saved in a kdesurc config file in /etc/trinity. Traditionally only admins have change permissions to /etc.

Perhaps there could be a default kdesurc in /usr/share/config, but the code looks in $SYSCONFDIR too for an admin system setting override.

A KControl portal keeps both sides happy. :)

kdesu does maintain a user's kdesurc file. If the user enables the check box, then the next time kdesu is run the check box is automatically enabled. Disable the check box and the next time kdesu is run the check box is empty.

Darrell

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

On Fri, Dec 2, 2011 at 5:46 PM, Darrell Anderson humanreadable@yahoo.comwrote:

...

IMHO, the save password dialog was always confusing (didn't say for how long it would save) and it a pretty big security liability. For me it is better to keep asking the password for everything that is admin related - no exceptions.

A "What's This?" tooltip popup could be added to the widget explaining the password is good only for that session and only for the period secified in defaults.h.

Or that same text could be added just below the check box widget.

Or both. :)

Proposed text:

Passwords are stored only in memory, only for each session, only for each app, and only for $PERIOD minutes.

The point again is some people want this feature and some don't. The only solution is to provide a mechanism to satisfy both crowds. Upstream developers should not decide --- let users decide. :)

They should decide when it's a feature that does not cause problems for anyone. I think that saving it in memory can be potentially exploited and is something that shouldn't be done. If there's one thing Linux does well is security (at least better...) and that is mostly due to asking for root user credentials when performing system related tasks. People usually like to use Windows with an admin account but, since they don't know any better, they end up with malware riddled systems after a short while and accept that as the norm, where if they would just keep it as a user account Windows systems are reasonably secured and malware free for a long time.

From my experience, performing admin tasks is so sporadic it doesn't deserve a feature like this. A power user has the better alternative to just login the root account and close it when it's done. I actually don't think kdm should be stopping you from logging in as root by default, since it is rather useful sometimes. It just should hide the root account from the user's list.

IMHO, if someone needs this feature, this should be explicitly enabled somewhere instead of exposing it to unknowing users which will just ignore any warning that's put up.

Best regards, Tiago

Best regards, Tiago

Darrell

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

On 2 December 2011 22:10, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:

Le Sat, 3 Dec 2011 02:05:59 +0000, Tiago Marques tiagomnm@gmail.com a écrit :

...

I think that saving it in memory can be potentially exploited and is something that shouldn't be done.

kdesud is protected against ptrace, at least in KDE 4.5. So I think the issue is whether we can trust the Linux kernel's memory protection. Also, KDE 4.5's "Keep password" feature (which is available in Slackware KDE packages) doesn't allow to re-use the password for another command, but only for the already launched application.

I think it is very important feature. How many times a day do I use sudo? Hundreds. I can't imagine having to literally retype my password every single time - it automagically lets me keep it for a certain session time. This would be good in Trinity as well.

Calvin

...

I think that saving it in memory can be potentially

exploited and is

...

something that shouldn't be done.

kdesud is protected against ptrace, at least in KDE 4.5. So I think the issue is whether we can trust the Linux kernel's memory protection. Also, KDE 4.5's "Keep password" feature (which is available in Slackware KDE packages) doesn't allow to re-use the password for another command, but only for the already launched application.

Yes, I mentioned that in my previous reply: the password is maintained only for one app, only for the current session, and only for the duratation specified in defaults.h. Not enabling the check box means the password must be re-entered for the same app, which is the same as the check box being disabled or invisible. Using kdesu with another app means retyping the password.

Then it is probably secured enough if implemented that way. Any idea of the situation in Trinity?

I can't imagine any changes from KDE3. Is there a way to test?

The fact that the option has been available for many years and still exists in KDE4 implies the feature is secure. Some distro maintainers disabled the check box, which is why many users never have seen the option, but the option has been available for many years from the untouched upstream KDE sources.

The kdesu --help options reveal that the check box can be disabled by using the -n parameter. Perhaps a desktop file could be created that specifies the default. Admins and end-users can override that default by editing the desktop file or copying the desktop file to their $KDEDIRS location and editing there. The underlying code would have to be revised to query that desktop file. That approach might be easier than creating a KControl option. Even in KControl, the default setting needs to be saved somewhere.

Darrell

So at it's core this is really a documentation issue. If the dialog box contained a single line stating the application the password is stored for and when the password storage will expire then I would be willing to add the checkbox back. Poorly defined or unknown/obscure behaviour is not a good thing when dealing with root access ;-)

The application is already stated in the dialog box. However, the text is not obvious and tends to just blend with the box. Perhaps the app information should be bolded or be more verbose. For example, use KRunner to type kdesu kate and this is what appears:

Command: kate

Perhaps that can be changed to:

Command: Run kate as root

I don't remember all the individual source files, but I seem to recall the "Keep password" check box widget is in kdelibs while the kdesu dialog box is part of kdebase. Any additional "notice" would have to be provided in the kdesu dialog box.

Right now the kdesu dialog looks like this:

======================================= Run as root - KDE su ======================================= The action you requested needs root privileges. Please enter root's password below or click Ignore to continue with your current privileges.

Command: kate Password: _________________

|_| Keep password

Ignore OK Cancel =======================================

Perhaps underneath the Keep password widget, only when the user enables the check box, the following text appears dynamically:

Keeping the password is good only for X hours, only for kate, and only for this session.

The duration X is fetched from defaults.h.

If the user does not enable the check box the text does not appear. By appearing dynamically, the potential security risk is more obvious. Or the warning text could be ghosted when the check box is disabled and unghosted when enabled.

Darrell