LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 07-16-2003, 07:51 AM   #1
mussons
LQ Newbie
 
Registered: Jul 2003
Posts: 5

Rep: Reputation: 0
Restricted shell to change the password


Hello,
How can I do a shell that just allow the user to change his password?...JUST change the password, so deny anything else.
Thanks a lot!
 
Old 07-16-2003, 05:19 PM   #2
Blinker_Fluid
Member
 
Registered: Jul 2003
Location: Clinging to my guns and religion.
Posts: 682

Rep: Reputation: 63
You would change the shell so it just goes to whatever you want
example of entry in /etc/passwd user named testing:
testing:x:6834:6834::/home/testing:/usr/bin/passwd
What happens when you log in:
[blinky@Spork ~]--> su - testing
Password:
Changing password for user testing.
Changing password for testing
(current) UNIX password:
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[blinky@Spork ~]-->
 
Old 07-17-2003, 01:41 AM   #3
mussons
LQ Newbie
 
Registered: Jul 2003
Posts: 5

Original Poster
Rep: Reputation: 0
THANKS A LOT, is exactly what I wanted...
 
Old 07-17-2003, 10:28 AM   #4
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,260
Blog Entries: 54

Rep: Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841
If there are no login restrictions and if there is no authentication before getting login/passwd, then you create a possibility for people to try bruteforcing passwd.
 
Old 07-17-2003, 11:25 AM   #5
Blinker_Fluid
Member
 
Registered: Jul 2003
Location: Clinging to my guns and religion.
Posts: 682

Rep: Reputation: 63
Quote:
Originally posted by unSpawn
If there are no login restrictions and if there is no authentication before getting login/passwd, then you create a possibility for people to try bruteforcing passwd.
So that's not how you would only allow the user to only change the password? Or are you talking enabling services like telnet, ssh, ftp, etc? I would agree that anytime you open up access to a box there is a security risk... but a box locked in a vault without power might be secure but not very usable...
 
Old 07-17-2003, 12:51 PM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,260
Blog Entries: 54

Rep: Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841
So that's not how you would only allow the user to only change the password?
No, that's *not* what I'm saying, the procedure itself isn't flawed AFAIK. Btw, I forgot to mention "secured connection"...

Using access restrictions (where possible), a separate passwd database and a SSL-wrapped tool is IMO the only real option. Using a separate database a daemon doesn't need access to the passwd/shadow files and the SSL-wrapped tool should make the connection somewhat trustworthy.


but a box locked in a vault without power might be secure but not very usable
That is a typical reaction, and I wonder why you made it (care to elaborate?).
IMHO risks should be either calculated (and then accompanied by restrictions making sure *you* remain in control), or the result of flawed reasoning (like saying "ease of use" is way more important).
 
Old 07-17-2003, 02:45 PM   #7
Blinker_Fluid
Member
 
Registered: Jul 2003
Location: Clinging to my guns and religion.
Posts: 682

Rep: Reputation: 63
Quote:
Originally posted by unSpawn

but a box locked in a vault without power might be secure but not very usable
That is a typical reaction, and I wonder why you made it (care to elaborate?).
IMHO risks should be either calculated (and then accompanied by restrictions making sure *you* remain in control), or the result of flawed reasoning (like saying "ease of use" is way more important).
I agree risks need to be calculated... I've just had too many Audit people come in and regurgitate the latest security thing to me. Like for example a windows flaw on a Unix system or having security so tight you have to authenticate 3 different times to find out what the cafeteria is having for lunch. (don't laugh I've seen it) Now I'm not saying that audit is bad and that security isn't important. I'm just saying security needs to fit the situation.
Some people may say it's good to change your root password every 6 weeks, the next thing you know management says if every 6 weeks is good every 3 must be better, next thing you know you're walking by desks and people have Root password: fuzzysl1pp3rs on a post-it note on the monitor.
I think everyone needs to ask themselves how much security they need and everyone will come up with a different answer. What is the data worth to you? What steps are you taking to preserve it? Is there something you can do to make things more secure? Are you willing to take the risk?
 
Old 07-17-2003, 08:00 PM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,260
Blog Entries: 54

Rep: Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841
I think everyone needs to ask themselves how much security they need and everyone will come up with a different answer.
I know what you're heading for, but unfortunately it doesn't work that way and you know it. Before you react, remind yourself this *is* a newbie-facing site, which means we're at the forefront of the security spearhead as far as I'm concerned.

Newbies in general don't take interest in securing their bright, shiny new toy with the go-faster stripes and the blinky icon lights, and not enough people point out it should be. Besides that "securing" is too often perceived as taking away (newfound) freedom, tedious, obscure The ability to make educated guesses about security issues requires rudimentary interest and knowledge, and that is not something we can expect (or get shown proof of) most of the time. Hell, most of the time a (possible) breach of compromise is presented something like "eeewww, my system is goin, like, all weird on me...", and preferably posted where I don't usually look (five pages deep in another forum).

So to me this means: raise awareness now, get in the discipline to perform basic hardening and maintenance routines, try to spark interest where we can and *then* pray they find the time and guts to actually *read* some basic docs before it's too late.

I'm not saying I'm bitter about the situation being as it is, but until someone shows a faint interest in doing the math wrt risks, that is how we need to "sell" the goods for now.
 
Old 07-18-2003, 01:49 PM   #9
enigmasoldier
Member
 
Registered: Jul 2003
Location: Florence, Ky
Distribution: CentOS 3.3-4, OpenBSD 3.3, Fedora Core 4, Ubuntu, Novell Open Enterprise Server
Posts: 213

Rep: Reputation: 30
Use sudo:

I was going to write exactly how to do it but this is just what you need.

Link
http://www.linux4biz.net/articles/sudo.html
 
Old 07-21-2003, 08:23 AM   #10
stickman
Senior Member
 
Registered: Sep 2002
Location: Nashville, TN
Posts: 1,552

Rep: Reputation: 53
Quote:
Originally posted by unSpawn
If there are no login restrictions and if there is no authentication before getting login/passwd, then you create a possibility for people to try bruteforcing passwd.
The system should still prompt for a login password before passing them off to /usr/sbin/passwd for a shell. At least that's what happened when I tested it on one of my systems. It's not an ideal solution, but it should work for non-high risk settings.

Last edited by stickman; 07-21-2003 at 08:24 AM.
 
Old 07-22-2003, 04:57 PM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,260
Blog Entries: 54

Rep: Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841
The system should still prompt for a login password before passing them off to /usr/sbin/passwd for a shell. At least that's what happened when I tested it on one of my systems. It's not an ideal solution, but it should work for non-high risk settings.

And what would you see as "low risk settings" usage?
And does that setup guard against brute forcing accounts?
Delving a bit deeper, what are good examples of situations where someone would need this b0rken kind of functionality?
I'm thinking of people who have an account on abox for accessing just one service, like an FTP stash, or a POP3 account. IMHO these type of acocunts shouldn't be served out of passwd/shadow, but a separate database.
 
Old 07-24-2003, 11:26 AM   #12
stickman
Senior Member
 
Registered: Sep 2002
Location: Nashville, TN
Posts: 1,552

Rep: Reputation: 53
I did say that is was not ideal, and it should be suitable for a trusted group of friends. I wouldn't use this in any sort of production environment. Personally, I don't even like giving people real user accounts unless they need access to the file system.
 
Old 07-24-2003, 10:05 PM   #13
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,260
Blog Entries: 54

Rep: Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841Reputation: 2841
It's only I'm just stumped by the lack of checking requirements before getting ready to answer in this thread, I won't exclude myself there.

//In my eyes this is more of a "meta" issue wrt solving security questions, and Blinker_Fluid already touched on the subject telling about prev experiences, and I can see how that can influence someone's attitude towards posting a possible solution for a "problem" a certain way, and how leaving out considerations/reasoning why/how a certain answer was given (esp. w/o enough background info) will set up the user with only an answer, and not info no build his/her own decision on. Guess we all have to try harder to approach (solving) these kind of security related issues not as a "one answer only" thing, but more of an if, elif (decision) tree...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Shell script to change password kamal_aitin Linux - General 6 07-25-2007 12:09 AM
How can I change e-mail password(or linux account password) with php in website?? yusuf Programming 1 05-28-2004 09:39 AM
Restricted Shell in RedHat 6.2 yuzuohong Linux - General 1 03-20-2003 09:06 AM
Restricted shell Rocket01 Linux - Software 3 01-23-2003 09:37 PM
Restricted Shell johnlee Linux - Security 3 10-29-2001 08:02 AM


All times are GMT -5. The time now is 12:10 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration