[TAG] lpr works for user not root in Basiclinux 2.1

[Ben Okopnik]

On Tue, Feb 27, 2007 at 12:13:34AM -0500, Sindi Keesan wrote:
> On Mon, 26 Feb 2007, Ben Okopnik wrote:
> >>
> >> We had a long discussion about why it is bad to go online as root, which
> >> is how Basiclinux is set up to operate.
> >>
> >> My current compromise is to:
> >>
> >> 1.  Dial as root (because dialing as user would give the user access to
> >> the login name and password, which would then let anyone with access to
> >> the user account know these, and besides if I try to dial as user pppd
> >> complains about not having /etc/ppp/options, which root does not need).
> >
> > Just to correct a misconception on your part: the information in
> > /etc/ppp/*-secrets does not have to be readable by the user; this is why
> > '/usr/sbin/pppd' is set SUID 0. In fact, that's the default
> > configuration on every Linux system I've seen, including the one I've
> > just set up on my new laptop:
> 
> We don't HAVE a /usr/sbin/pppd.  

The fact that you've emphasized this implies that you find it
meaningful, but I'm at a loss as to why. You clearly have a 'pppd'
*somewhere*; this means that you can follow the same method as everyone
else who uses 'pppd' - i.e., make the executable SUID 0 and executable
by some group, then make those users who should be able to dial out part
of that group. Where's the problem?

> We use eznet to dial with (it tells pppd 
> what to do) and it uses /var/eznet/eznet.conf which contains login info.
> 
> When I try to dial as user, pppd wants /etc/ppp/options (which we also do 
> not have).

Honestly, this is getting rather silly. If your software complains about
not having some file - particularly if that file doesn't need to have
anything special in it and doesn't require a large amount of space -
then why not create it, perhaps by copying it from a working system?  In
the case of '/etc/ppp/options', on my system, it's just a tiny text file
that contains about 100 bytes of non-comment text:

``
ben at Tyr:~$ grep '^[^#]' /etc/ppp/options
asyncmap 0
auth
crtscts
lock
hide-password
modem
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
noipx
''

> > ``
> > ben at Tyr:~$ ls -l /usr/sbin/pppd /etc/ppp/*secrets
> > -rw------- 1 root root     80 2006-05-30 20:58 /etc/ppp/chap-secrets
> > -rw------- 1 root root   1628 2006-05-30 20:58 /etc/ppp/pap-secrets
> > -rwsr-xr-- 1 root dip  306720 2006-07-05 06:22 /usr/sbin/pppd
> > '''
> >
> > The above means that any user who is part of group 'dip' can execute
> > 'pppd' - and since 'pppd' runs as root, it can read the files that
> > contain the name and the password.
> 
> In my attempts to dial I ended up with pppd -rwsr-sr-x root root
> I am experimenting ....
> chgrp users pppd  chmod o-r pppd    chmod g-s pppd
> 
> Ten minutes later I have -rwsr-xr-- root users pppd

Well, Sindi... if you don't explicitly mention that you need help with
permissions/ownership, then you're not likely to get it. Reading the
relevant manpages would have helped, and in significantly less than 10
minutes (and please don't tell me that you don't have them on your
system; at this point, searching google for "man chmod" brings up the
'chmod' manpage as the first hit.)

``
chown root.pppd pppd
chmod 4754 pppd
''

> This linux came with one 'user' login who lives in /home/user and uses 
> /bin/sh.  Root uses /bin/bash (according to /etc/passwd).  I had to make 
> /home/user owned by user (chown -R user user chgrp -R users user) before I 
> could save anything to it.  As I said, this is a single-user distribution.

Clearly a very badly-configured one. A home directory where you can't
save anything as that user? That's pretty bad.
 
> I compiled a new busybox which has adduser and addgroup (my linux had 
> neither).  I have used adduser once.

Perhaps you should use 'useradd' instead. 'adduser', etc., are front
ends to that whole toolkit.
 
> addgroup users tells me it is already in use.

The simplest way to add an existing user to an existing group is by
editing '/etc/group'. The _safe_ and simple way to do it is by using
'vigr'.
 
> Next problem is that we are dialing with eznet not directly with pppd.
> 
> My pap-secrets is also not world-readable and it contains the same login 
> and password info as eznet.conf.  I don't know where eznet looks for 
> info.

I'm not familiar with 'eznet' - I've never used it. Anytime I need to
connect by dialing - and I do this every day with my Aircard - I just
use 'pppd' directly (e.g., 'pppd call aircard' for the 'aircard'
configuration.) I do this as a non-root user, and haven't had any
problems related to the functioning of 'pppd' itself.
 
> I think you are saying if I set pppd SUID, then the user can use pppd, 
> which can read the login and password info from pap-secrets, but the user 
> cannot do that directly, so it is safe.  But I don't know how to dial with 
> pppd directly, just via eznet.

Based on what you've said (i.e., that eznet is a front end to pppd),
'pppd' is already configured for you - the only thing you need to do is
find out what the name of the configuration files is. Fortunately,
that's pretty easy: take a look at '/etc/ppp/peers' - this contains all
your "dialup configurations". If these don't contain root-only options
such as 'noauth' (and there's rarely any reason for having such
options), then a non-root user can just enter

``
pppd call foo
''

where 'foo' is the name of the config file from '/etc/ppp/peers', to
dial.
'
 
> Does the following help any:
> 
> I can type 'eznet up 4' to get the fourth login and password etc. (set up 
> to use the lucent modem) listed in eznet.conf.  ps lists as a process:
> 
> /usr/sbin/pppd /dev/ttyLT0 115200 connect /usr/bin/eznet chat 4 
> defaultroute lock modem mtu 552 mru 5 (goes off the screen).

If you use the 'w' option to 'ps', it'll wrap the line.
 
> > In other words, it appears as though you're taking a mechanism that
> > works just fine and changing it so that it will do the same thing as
> > it's doing now. I suggest that understanding the current mechanism would
> > serve you better than trying to construct something new from the ground
> > up - especially since it's not new.
> 
> I don't have the standard setup to start with.

Then whoever set up the distro broke that standard setup for no reason.
In fact, that sounds like the core of all your problems - pretty much
everything you've asked here in this regard has been a standard
"question" in Unix that got answered a long time ago by either designing
a better system or defining a specific method for dealing with the
problem. In addition, all these things have been refined and "tuned"
over time to eliminate or avoid security problems, problematic edge
cases, etc. Now, it sounds like whoever put this distro together has
recreated these ancient problems - and you're stuck trying to solve
them. The only question, given the plethora of other, *well-working*
distros out there is "why"?

If you were doing this because you wanted to learn how to solve
low-level Linux problems, perhaps this would be a good approach.
However, you keep mentioning having to accomodate users; this is like
trying to design a brand-new type of chainsaw and handing it out to
random people to use while it's still in the prototype stage. The
results that you're getting are - well, exactly what could be expected
of such actions.
 
> > In that case, either recompiling 'ssh' to look for 'ssh_askpass' in a
> > different place, or creating the above path and a link to the
> > actual location of 'ssh_askpass' should help.
> 
> I don't know how to compile ssh.

Then create the path, as I've mentioned.

> This reply took a couple of hours.  I am learning a lot.  Thanks.

I'm glad that you're finding this helpful, but you're working with a
broken system and learning many lessons that are going to be useless in
normal scenarios (along with some that will be useful.) I would
seriously suggest exploring other distros.


-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *