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? Darrell

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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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

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. :)

Darrell --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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

Le Sat, 3 Dec 2011 02:05:59 +0000, Tiago Marques <tiagomnm(a)gmail.com> a écrit : 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.

exploited and is 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.

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

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 ;-)