30 Nov
2011
30 Nov
'11
3 a.m.
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
30 Nov
30 Nov
5:10 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
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
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.
Tim
7:10 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
I submitted a
patch to bug
report 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. 
2 Dec
2 Dec
6:50 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
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(a)yahoo.com>wrote;wrote:
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
I submitted a patch to bug
report 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.
5:46 p.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
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. :)
Darrell
3 Dec
3 Dec
2:05 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
On Fri, Dec 2, 2011 at 5:46 PM, Darrell Anderson <humanreadable(a)yahoo.com>wrote;wrote:
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
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. :)
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
3:10 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
Le Sat, 3 Dec 2011 02:05:59 +0000,
Tiago Marques <tiagomnm(a)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.
3:15 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
On 2 December 2011 22:10, /dev/ammo42 <mickeytintincolle(a)yahoo.fr> wrote:
Le Sat, 3 Dec 2011 02:05:59 +0000,
Tiago Marques <tiagomnm(a)gmail.com> a écrit :
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.
9:37 p.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
On Sat, Dec 3, 2011 at 3:10 AM, /dev/ammo42 <mickeytintincolle(a)yahoo.fr>wrote;wrote:
Le Sat, 3 Dec 2011 02:05:59 +0000,
Tiago Marques <tiagomnm(a)gmail.com> a écrit :
Then it is probably secured enough if implemented that way. Any idea of the
situation in Trinity?
Best regards,
Tiago
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.
---------------------------------------------------------------------
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
4 Dec
4 Dec
12:21 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
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. 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
1:12 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
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. 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
3:38 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
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
3:48 a.m.
New subject: [trinity-devel] "Keep password" check box restored to kdesu dialog box
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
4520
days inactive
4524
days old
12 comments
5 participants
participants (5)
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
Tiago Marques -
Timothy Pearson