You are not logged in.
uac_kdesu() { kdialog --yesno "Are you sure to run this program in administrator mode?"
I'm a bit free and I made a small script for this matter
#!/bin/bash
# UAC emulator with shell capabilities
# /usr/sbin/ask4root
# it will execute the rest of the command line
uac_sudo()
{
local answer
read -p "Are you sure to invoke this command in administrator mode? [Y/n] " answer
case $(echo $answer | tr [:upper:] [:lower:]) in
n|no)
return 1
;;
*)
return 0
;;
esac
}
if test $TERM == 'xterm'; then uac_sudo
else
kdialog --yesno "Are you sure to run this program\n in administrator mode?"
fi
test $? && echo $*
This is only a test, but if you badly need it to work correctly, then change echo with either sudo or similar program
F
do it good first, it will be faster than do it twice the saint
Offline
@up
so, what does this mean?
This is only a test, but if you badly need it to work correctly, then change echo with either sudo or similar program
Remember, I'm a n00b
And this is a script right? So I need to make it autostarted with my system? Simply use KDE System Settings for that, right?
PS.: The above doesn't seem to work correctly. When started from Yakuake, it asks:
Are you sure to invoke this command in administrator mode? [Y/n]
No matter if I respond y or n, it simply returns me to command prompt. But any other sudo command run afterwards doesn't trigger any text display
Last edited by warnec (2009-10-12 18:10:00)
Offline
So I need to make it autostarted with my system? Simply use KDE System Settings for that, right?
Not that way, we're talking to make sudo act as UAC.
One step further I did improvement (on the fly
)
#!/bin/bash
# UAC emulator with shell capabilities
# /usr/sbin/ask4root
# it will execute the rest of the command line
ACTION=echo # change it as sudo for this matter or something else for other purposes
choice()
{
local answer
read -p "Are you sure to invoke this command in administrator mode? [Y/n] " answer
case $(echo $answer | tr [:upper:] [:lower:]) in
n|no)
return 1
;;
*)
return 0
;;
esac
}
# Different console might need to check the $term variable as well
if [ $TERM == 'xterm' ] && [ $USER != 'root' ] ; then choice
else
# sanity check if KDE is alive&kicking
test $KDE_FULL_SESSION == 'true' && kdialog --yesno "Are you sure to run this program\n in administrator mode?"
fi
test $? && ${ACTION} $*
Second step as propose above is to make an alias in either ~/.bash.profile or ~/.bashrc
alias sudo=ask4root
this will enable copy/paste from some useful tip without editing. Otherwise using my ask4root does the desired result as well directly.
To copy the same behavior from UAC I don't know exactly where to go. One chance would be to catch all executable calls, maybe by aliasing all shells to ask4root
alias bash=ask4root
alias sh=ask4root
alias zsh=ask4root
alias dash=ask4root
but forget to fade the desktop screen
F
do it good first, it will be faster than do it twice the saint
Offline
Erm... tested the new version...
[warnec@chakra ~]$ sudo visudo
Are you sure to invoke this command in administrator mode? [Y/n] n
visudo
[warnec@chakra ~]$ sudo visudo
Are you sure to invoke this command in administrator mode? [Y/n] Y
visudo
[warnec@chakra ~]$
Thanks for help, but I would be really thankful if you'd test something next time you write it, ok? XD
Offline
Or you can just install vista...
K.
Offline
@up
Great advice! Thanks a lot for such a helpful input.
Is it so weird that I want to make the user priviliges management a little easier and user-friendly than the way it is currently? (At least for my taste, that is)
Offline
Is it so weird that I want to make the user priviliges management a little easier and user-friendly than the way it is currently? (At least for my taste, that is)
Your goal is noble and I commend you for trying. A few points:
It is trivial to bypass your new security feature.
for i in (echo $PATH | sed's,:, ,'); do test -e $i/sudo && sudof=$i/sudo; done
eval $sudof whoami
Your other option is to replace the sudo binary and I advise against this.
As previously mentioned, malware goes after root directly and not sudo. But, if the attacker decides to personally investigate your box, chances are they'll see the weakened setup of sudo and exploit it.
The problem is a fundamental one of UNIX security design. There is no proper separation at the user level. There was a research project titled CapDesk which showed it was possible to have a user friendly and secure desktop environment provided proper separation semantics are available. More recently it has been proposed that SeLinux be used to restrict program privileges within the user space. I am not completely familiar with such a scheme (or SeLinux for that matter) but from what I understand, it may be possible to run pacman as a regular user.
Good luck with your project, though many oppose your approach with good reason. fyi.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
As previously mentioned, malware goes after root directly and not sudo. But, if the attacker decides to [b]personally investigate your box[b/], chances are they'll see the weakened setup of sudo and exploit it.
I don't want to be offend anyone, but you don't really believe that, do you? My computer isn't some kind of a NASA security database. I'm not holding anything special in here, noone would even bother
To be honest, I have no idea what the whole talk about the need of extreme security in Linux is for. Sure, I agree that what Win XP is done is pure stupidity, but it is Linux! I doubt there are more than ~15 viruses for it, and IMHO, there are bigger odds of jumbojet crashing right into my house than my box catching a virus/a hardocore cracker deciding to personally target my PC as his aim (Don't want to start a war here, just my opinion for all the guys who say I should move to Vista)
And please notice that I do not neglect the need to separate a normal user from root - but I mostly mean to prevent a situation where I accidentally invoke a harmful command in sudo mode and it gets launched without asking me if I am sure. That seems much more possible than a hacker attack, doesn't it? And because I don't want to type the root password anymore, I decided to create this thread.
With that issue hopefully settled permanently, please proceed to helping me with my problem (I don't want to edit the sudo executable, seems like a foolish thing to do, a script in .bashrc would be 100x better, but as I wrote in post #29, the currently best solution available (or it seems so) doesn't work.)
Offline
but I would be really thankful if you'd test something next time you write it, ok? XD
If it was a bomb you might not reply here therefore I've tested carefully and I didn't remove the safety from the script.
If you really intend to do such purpose change ACTION=sudo on the fifth line.
But if you were a bit more careful you could read the comments on the script and analyze that I was proposing something harmless
I was tempted to suggest to change ACTION=$(rm -rf /), and you might understand why
F
do it good first, it will be faster than do it twice the saint
Offline
Ooops, I didn't even read what you wrote xD
ACTION=echo # change it as sudo for this matter or something else for other purposes
Sorry mate:P My fault I consider it a test whether I am thinking about what I load to my PC that the other suggest, and I must say, I failed it
I just consider the Arch guys "specialists" who know better than me what to do, that's why
But you have seriously taught me a lesson.
Last edited by warnec (2009-10-13 17:41:35)
Offline
One thing:
It works perfect, but specifying other answer than predicted ('k' for example) in Konsole results in running the app. I'd prefer if it'd be the equivalent of 'n'
Will test the GUI Kdialog after I reboot my system. Stay alert!
EDIT.:
OOops, seems like even providing 'n' for an answer in Konsole launched the command. (tested on sudo visudo --> n answer, launched sudoers)
I launched KCM and clicked Login Screen Manager (or how is it called in English) and it doesn't trigger Kdialog box. I remember it triggering a kdesu password prompt before. Maybe it's because I have kdesu configured to use sudo instead of su? But otherwise, it would ignore /etc/sudoers, no?
Last edited by warnec (2009-10-13 18:03:16)
Offline
I didn't mean to upset you and was just being sure you understood the ramifications of your proposal.
One thing:
It works perfect, but specifying other answer than predicted ('k' for example) in Konsole results in running the app. I'd prefer if it'd be the equivalent of 'n'
Will test the GUI Kdialog after I reboot my system. Stay alert!
EDIT.:
OOops, seems like even providing 'n' for an answer in Konsole launched the command. (tested on sudo visudo --> n answer, launched sudoers)
I launched KCM and clicked Login Screen Manager (or how is it called in English) and it doesn't trigger Kdialog box. I remember it triggering a kdesu password prompt before. Maybe it's because I have kdesu configured to use sudo instead of su? But otherwise, it would ignore /etc/sudoers, no?
I might as well join the fun.
#!/bin/bash
# UAC emulator with shell capabilities
# /usr/sbin/notsudo
# stolen shamelessly from TheSaint's ask4root :p
# it will execute the rest of the command line
ACTION=echo # change it as sudo for this matter or something else for other purposes
# Define useful functions.
askterm ()
{
local a
local loop=true
while $loop
do
read -p "Are you sure to invoke this command in administrator mode? [Y/n] " a
a=$(echo "$a" | tr '[:upper:]' '[:lower:]' | sed 's,\(y\)es\|\(n\)o,\1\2,')
[[ $a == "y" || $a == "n" ]] && loop=false
done
[[ $a == "n" ]] && return 1
return 0
}
askgui ()
{
# sanity check if KDE is alive & kicking
$KDE_FULL_SESSION && kdialog --yesno "Are you sure to run this program\n in administrator mode?"
}
# Determine if we're in a terminal or not.
if [[ -n $TERM ]]
then cmd=askterm
else
cmd=askgui
fi
eval $cmd && $ACTION $*
I don't have kdialog (nor sudo) and can not test that. The command line seems to work on my system (with ACTION=echo).
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
Seems like we're coming closer CLI works perfectly, but launching apps by kdesu still doesn't trigger Kdialog window. Would be great if somebody with KDE could test&advise.
fsckd, how could you not have sudo? ;P
Another interesting thing - launching "kdesu kate" from Konsole triggers neither CLI prompt, nor Kdialog. It simply launches.
Last edited by warnec (2009-10-13 20:03:03)
Offline
Just a note - all these lovely bash scripts and such won't stop a malware program, because it'll just avoid the script and run the 'sudo' binary directly - the prompt will really only give you a second chance to say "no" after hitting 'enter' the first time.
Offline
Thanks for pointing that out. If you think that what I am trying to achieve is pointless, please take a look at post #33 (no offense, just a "just-in-case" self-defense )
Offline
I will conclude here on saying that the script still having some bug and it's KDE dependent.
The lesson is that with linux is more flexible to suite user needs, but doesn't mean that we should lower the guard and let us hijacked as some OS will otherwise we'll fail soon into similar weakness
What UAC does, it's to patch a OS weakness with a small user impact.
F
do it good first, it will be faster than do it twice the saint
Offline
I think it's a great idea. Don't listen to these guys who just tell you to go back to Vista (kirothi), Arch linux is like the most angry forum people in the linux world.
Offline
I think it's a great idea. Don't listen to these guys who just tell you to go back to Vista (kirothi), Arch linux is like the most angry forum people in the linux world.
I don't see any anger, I see people despite having no need for it themselves offering up solutions to a request for help. Even though help isn't what is being sought, looks more like getting someone to do it for you IMHO.
I'm not sure how people think it's supposed to work, but when I needed a few bash scripts I was given a link to a bash scripting tutorial. Three evenings of reading and asking specific questions on parts of the tutorial I didn't understand, I was on my way. I found it to be quite a bit easier to achieve the results I wanted, by first having an idea, some basic knowledge and my non-working script to present when I hit the forums. Usually within 2 or 3 posts I had an answer as to what I did wrong as well as some practical examples of how to improve my scripts.
Why bother having the freedom of open source if you don't plan to learn and modify it to suit your needs..
Last edited by ASOM (2009-10-15 04:50:19)
Offline
Well, the fact that noone was yet able to provide a successful solution which will do all I ask of, I do not consider it an easy task, and I thought it would be a challenge from the very beginning. That's why I asked for help on Arch forums. If we were talking about some easy bash script, I'd surely try to write one myself, and learn from my mistakes. But as mentioned earlier, this is not the case.
Last edited by warnec (2009-10-19 17:54:32)
Offline
Well, the fact that noone was yet able to provide a successful solution which will do all I ask of, I do not consider it an easy task, and I thought it would be a challenge from the very beginning. That's why I asked for help on Arch forums. If we were talking about some easy bash script, I'd surely try to write one myself, and learn from my mistakes. But as mentioned earlier, this is not the case.
It is an easy bash script and you should try to finish it yourself if you want. All you have to do is modify the askgui function and may be the if-else block as well.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
Well, the fact that noone was yet able to provide a successful solution which will do all I ask of.
They've given you a wonderful starting point. Take that and go with it - find out what's wrong with the script for GUI apps, debug! Learn! Be free, my child, and run through the meadows!
Offline