Passing passwords

Started by benthehutt, August 28, 2005, 04:12:56 PM

Previous topic - Next topic
If you run any command and it needs a certain username/passwd, how can you pass it into the command, other than using sudo?  Can you write a setuid script from a shell script for various other users and then use that, or is that a stupid idea?

I know some commands have that built in like smbclient, but is there anyway that works for all of them, not just the ones that have that built in?
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

You should _NEVER_ have a SUID bit on a file unless you absolutely need it ... (eg. the passwd command needs it); if there is a bug that is exploitable (buffer overflow for instance), you risk the chance of a compromised in(?)security system.

As for your other question:

I'd say if you can't do it with unix pipes, then it probably depends on the command/program you're using. And I'd advise against it anyway.

lots of commands (eg ssh) have a -l option (or equivalent) to pass the login, but no password option (and if it did have it I'd advise against it).

If you don't take precautions, it's very possible it could be intercepted (.bash_history or any other numerous ways, some examples below).

Another example:

If this is on a machine others are on... think of the 'w' command or 'ps' command or 'top' command ...

Or what happens if (hypothetically speaking) you have a trojan horse installed ... (maybe it logs to a different file everything you type...)

And other examples I'm sure.

But to recap:

- Don't go the suid route for something like this ... bad idea
- Be careful if you're providing passwords on the command line.
- the commands/programs don't provide that option for a reason; but if you must you can try unix pipes or so (or some programs allow you to not require passwords).

Hope that helps


"My Terminal is my Soul"

Whoa, didn't know it was so dangerous.  Could you perhaps elaborate on doing it with pipes, I only ask from pure curiosity of the syntax.  For instance, connecting to a smb server with smbclient goes like this:

smbclient //ss1/Win_Apps -U bmj465

then it asks for a password.  Are you saying pipes can be used everytime in a consistent manner, or every command does it differently?  Either way, how would you do it with smbclient?

And also, just out of curiosity, how would I go about the SUID route?  I'm not quite sure how to set the SUID bit.  Or, would it even work in this instance?

Sorry for all the questions, I'm just trying to learn...
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

Firstly, Don't worry about asking too many questions.

Suid bits can be set on the file with the 'chmod' command (man chmod for more info). I refer you to the man page because you can do it in more than one 'way' (octal mode and alpha mode).

Whether it'd work or not.. I don't know.. what are you trying to accomplish ? You could of course configure certain programs/protocols to not require a password at all (not recommended of course).

Unix pipes are an interesting subject. They connect the standard output of one command to the standard input of another command.

An example would be..

ls -alR / | less

which would do a recursive, long listing of every file in the / directory  (assuming you have exec and read access on the directories). But, then it'd send it to less, so that you can view it one page at a time.

That's a simple example.

As for passwords.. I'm not sure it would work. I just meant if it were to work, it'd have to be something a bit more advanced.

I think it won't work because it's not immediately needed, and the pipe already does its work (hopefully that makes sense).

It may be possible, but I can't think of a way right now. I'd suggest you look up unix pipes (and related things such as redirection of data etc) for more info.

I don't know if I answered all your questions, because I'm really quite tired. If I didn't though, just mention it and I'll try my best to answer when I'm more alive.
"My Terminal is my Soul"

I guess I wasn't very clear at all, sorry.  I know all about chmod (OCTAL MODE ALL THE WAY!!), what I really wanted to know is if you could build something like sudo, (where it lets a normal user run a command as if they were the root user) except in my version it would let you run a command as some other user.  I thought this might be possible by fiddlin' with SUID bits and whatnot, but maybe I'm barking up the wrong tree...

I think I understand why it probably wouldn't work with pipes.  You're saying that all the info passes at once, before whatever you're accessing has the chance to ask for a password, right?
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

btw, I could alternatively su to the other users profile, but that would just add further username/PW troubles...
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

Well, take this for example:

metgod@deranged ~ $ ssh metgod@localhost | echo test
test
Password:


(of course that's just a simple example that may or may not be the best -- point is that the output of the first command is connected to input of the second stream, _but_ you can do all sorts of stuff depending on which commands you're using).

That being noted, you can configure certain programs to not require a password. Just use caution with that of course (i'd have to look it up as I don't remember it off hand).

About suid.. I don't think it's what you're after ... at least not entirely. The problem is, how is the program (if it's not root) supposed to change it's permissions ? Take for instance a system that has 2+ users (other than the normal system accounts).

We'll call them 'user1'  (id 1000) and 'user2' (id 1001).

Let's say that user1 writes a program that will try to change the program/process to a specified uid/euid.

Now they try to run it with a passed arg... '1001'.

It fails because it doesn't have the right permissions (unless the person running it is actually root/uid 0).

If you remove the suid bit on 'su' for example, then you will basically break the command ... But this very fact is why you should be careful to not have suid files that you absolutely don't need.

Are there ways around this all ? I'm pretty sure there are, but I'm not sure of them all.

if you have any more questions, feel free to ask and I'll try to answer (and hopefully these are satisfactory enough answers).
"My Terminal is my Soul"

August 29, 2005, 02:33:22 PM #7 Last Edit: August 29, 2005, 02:35:33 PM by Metgod
As another example, consider the below code (just wrote it real quickly so forgive the ugliness):

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
int main(int argc, char **argv)
{
  if (argc != 2)
        {
        fprintf(stderr, "Usage: %s <uid>\n", argv[0]);
        return 1;
        }

  printf("Attempting to change to uid specified ...");
  if (setuid(atoi(argv[1])) < 0)
        printf("Failed ... uid is still %d\n", getuid());
  else  printf("Success!\n");
  return 0;
}


If you try to run this as a normal user, and you specify an id other than yours, you'll see it fails.

But if you make it suid AND change the owner to root, then you can specify any id that is valid and it'll succeed.

If you make it suid and do NOT change the owner, then you'll see any id other than yours will fail.

EDIT:

I'm sure you can (now if not before) see why it's dangerous to have suid files lying around. If any contain an exploitable bug, then you risk the chance of shell code being injected (for example), thus a root shell very likely being created.
"My Terminal is my Soul"

I do see the dangers in having suid files lying around, but all that aside (I'm more interested in the "theory" behind it) I don't know if you quite understood my question...  I'll start from the beginning and provide as much info as I can:

Problem:  I want to connect to many different remote smb/cifs servers, but I want to be able to just run a script to do it instead of opening up the terminal and entering many different smbclient command requests.  Thusly, I would like to find a way (it can be ugly since I'll never see it again) to connect to them, passing my username and password to them so I can run the script and be connected to all of them.

Solutions:  My first theoretical approach was to create something similar to the "sudo" command (or use the sudo command) to run the smbclient command as the user that has full access to the smb servers (who is different than me), therefore eliminating need of entering a username or password.  In sudo, the command just checks /etc/sudoers for a list of users that have permission to use it.  I was wondering if you could make a similar list for another users permissions, eg. instead of root privileges, you would have a different users privileges.

The second theoretical approach (you came up with) was to pipe the password into the smbclient command somehow, etc., etc.

I'm sorry if I'm being difficult, I suppose I didn't know how to pose the question I was after an answer to. ;D
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

btw, the real smbclient syntax would be:

smbclient \/\/ss1\/Win_Apps -U bmj465

(You have to escape the /'s)
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

Sudo:

http://www.gentoo.org/doc/en/sudo-guide.xml

That's a nice overview of the sudo program. You might want to check out the man pages to sudoers and sudo of course (and maybe the website of the sudo program itself).

I'm unfortunately (for you) very ignorant when it comes to samba. Personally, if I had to get access to those drives, I'd either mount them (if in same machine and kernel config allows it) or just login to the machine (different machine) physically. But honestly maybe samba has other benefits (really don't know since I have no need for it).

Let me know if you need any more help. Hopefully the sudo article will be of a good help to get what you're after (since you said it might be a solution...).
"My Terminal is my Soul"

It's on a different machine, so I can't just mount them, and the servers are configed to kick you off after a certain period (also when you shut down the computer).  Anyway, thanks for the info, I learned alot more from all the stuff you said then I thought I'd learn, whew.  I looked over that sudo link you gave me, turns out it's alot more complicated than I initially thought so I'll probably try and figure out the pipe method.

Thx again, you're a great help! ;D
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

Well, it might be worth it to learn sudo. There was really only one part of it though, that matters (if you've already configured sudo). It's simply adding a line to say which users can run this stuff as.

I would be curious to see your solution if you don't go that way. I don't know how samba works, so can't really offer much help there I'm afraid.

Glad I could be of help otherwise, though!

Let me know how it goes or if you have any other thoughts/concerns/questions.
"My Terminal is my Soul"

Oh yeah, I didn't mean I wasn't going to learn bout sudo.  I try to learn everything about everything I possibly can.  Sudo's neat and powerful and all, but I was looking for something less involved than that. Though, the way my research is going, I'd say using pipes is going to be pretty ugly...(if not impossible)
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

Yup.. I don't think it is in this case (which I think I said above somewhere). But just meant if it is possible it may be that way. But if is the keyword.

I'll see if I can come up with any other ways though. will let you know if I come up with anything.
"My Terminal is my Soul"

SMF spam blocked by CleanTalk