Linux rsh BIG RAGGEDY HOLE
Graham Toal
:If this has been discussed already, ignore this msg.
:
:The Linux boxes I've examined so far come with
:
: root::0:0:random-string:/:/bin/sh
:
:in /etc/passwd. This is fine since most incoming servers use the shadow
:mechanism, but rshd does NOT check /etc/shadow. It just lets you in.
OUCH!!! I thought 'No, can't apply to me, I have quite a recent Linux
here (like maybe 3 months old). It did... and would have given *anyone*
root access to a machine on our net and the ability to hop to any other
machine relatively easily :-(
Folks, check this yourselves if you have linux. Just do:
rsh -l root localhost whoami
to check if you're exposed. Then edit /etc/passwd and put the '*'
in every :: password field. Don't worry, it's not removed next
time you change your passwd properly.
Thanks for pointing that out, Hobbit.
:This is being CCed to CERT and CIAC. Let's see what they do with it.
Oh come on, you know the answer by now :-)
G
Christopher Samuel
gt...@an-teallach.com (Graham Toal) doodled:
[Linux shadow passwd hole sacrificed to line eater]
> OUCH!!! I thought 'No, can't apply to me, I have quite a recent Linux
> here (like maybe 3 months old). It did... and would have given
> *anyone* root access to a machine on our net and the ability to hop to
> any other machine relatively easily :-(
Coo, makes me glad that I'm not running shadow passwords on my PC on my
desk.. How wisespread is the use of shadow passwords on Linux ?
I suspect I escaped this because I picked up the MCC interim release,
and I believe that is still at pl12..
Chris
--
Christopher Samuel, Computer Unit, U.W Aberystwyth, Aberystwyth, WALES
E-mail: c...@aber.ac.uk PGP 2.3 public key available on request
Then hast thou joined the ARPANET? Oh come to me, my bankrupt boy!
Quick, call the NIC! Send RFCs! He chortled in his joy. - RFC527
Matthew J Brown
> In article <1993120213...@an-teallach.com>
> gt...@an-teallach.com (Graham Toal) doodled:
> [Linux shadow passwd hole sacrificed to line eater]
>> OUCH!!! I thought 'No, can't apply to me, I have quite a recent Linux
>> here (like maybe 3 months old). It did... and would have given
>> *anyone* root access to a machine on our net and the ability to hop to
>> any other machine relatively easily :-(
> Coo, makes me glad that I'm not running shadow passwords on my PC on my
> desk.. How wisespread is the use of shadow passwords on Linux ?
> I suspect I escaped this because I picked up the MCC interim release,
> and I believe that is still at pl12..
The above from Christopher makes it sound like shadow passwords are
the problem, which of course isn't so. The problem is (1) that
/etc/passwd has been setup badly so that programs which don't know
about shadow passwords find a valid (in fact, null) password there,
and (2) that rshd doesn't know about shadow passwords.
Don't junk the shadow password system, folks. Just make sure the
password field in /etc/password contains an invalid password (eg '*').
-Morven
--
______ Morven -- m...@doc.ic.ac.uk -- m.b...@ic.ac.uk -- Matthew Jude Brown
\ __/___ Dept of Computing, Imperial College, 180 Queens Gate, London SW7 2AZ
\ \/ / 45 Ollgar Close, Shepherd's Bush, London W12 0NG -- Tel 081-740 0271
\/\ / --------------------------------------------------------------------
\/ | Teamwork is essential --- it allows you to blame someone else. |
laz
Christopher Samuel <c...@aber.ac.uk> wrote:
>Coo, makes me glad that I'm not running shadow passwords on my PC on my
>desk.. How wisespread is the use of shadow passwords on Linux ?
I'd say the majority of linux users use the SLS and Slackware distributions.
Both of these incorporate the shadow password suite. SLS in particular is
notorious for being shipped with horrendous permission settings. Supposedly
linux also has the shared library security problems that have plagued other
UNIXes. Linux was never meant to be a secure OS, and it shouldn't be treated
as such. With the widespread distribution of its source, people with a little
initiative could find holes rather easily I'd say.
laz
Timothy Newsham
>UNIXes. Linux was never meant to be a secure OS, and it shouldn't be treated
>as such. With the widespread distribution of its source, people with a little
>initiative could find holes rather easily I'd say.
This will (in the long run) make linux more secure, not a less secure
environmen.
>laz
David L. Craig
>
> I'd say the majority of linux users use the SLS and Slackware distributions.
There was a big discussion of this several months ago within the
comp.os.linux hierarchy. I'm surprised that followers of this
newsgroup who use Linux don't follow c.o.l.* -- you can't expect
anyone to call you up and say, "by the way, ..." Of course,
there are some Linux sites without USENET access...
Graham Toal
:There was a big discussion of this several months ago within the
:comp.os.linux hierarchy. I'm surprised that followers of this
:newsgroup who use Linux don't follow c.o.l.* -- you can't expect
:anyone to call you up and say, "by the way, ..." Of course,
:there are some Linux sites without USENET access...
I have linux, 386bsd, bsdi, dell, UnixWare, and SCO at this site. I also
have a full-time job programming. I can't afford the time to wade through
another 20 newsgroups to follow everything that's said on the groups for
all these systems in the hope of spotting something I need to know about
their security. Comp.security.{misc|unix} is the place to announce problems
like that; that's what the crossposting mechanism was invented for. If it
hadn't have been for hobbit having the sense to tell us, I'd never have
known about that *nasty nasty nasty* hole. (I used to rely on CERT posting
announcements of such problems, but now I know better. If my understanding
of CERT is correct, I don't ever expect to see any announcements of holes
in free OS's that don't also exist in proprietary ones...)
G
Tom Holub
)as such.
^Linu^Uni
-Tom
Tom Christiansen
:I have linux, 386bsd, bsdi, dell, UnixWare, and SCO at this site. I also
:have a full-time job programming. I can't afford the time to wade through
:another 20 newsgroups to follow everything that's said on the groups for
:all these systems in the hope of spotting something I need to know about
:their security. Comp.security.{misc|unix} is the place to announce problems
:like that; that's what the crossposting mechanism was invented for. If it
:hadn't have been for hobbit having the sense to tell us, I'd never have
:known about that *nasty nasty nasty* hole.
First, I agree with what Graham has said.
I may be able to offer some small bit of help. If you have access to
your news spool (nntp won't cut it), then you can run Larry Wall's clip
program to help alert you to thing you can describe . The program is
available for anon ftp from convex.com in /pub/perl/scripts/clip; it's
pretty neat.
:(I used to rely on CERT posting
:announcements of such problems, but now I know better. If my understanding
:of CERT is correct, I don't ever expect to see any announcements of holes
:in free OS's that don't also exist in proprietary ones...)
*SIGH*.
--tom
--
Tom Christiansen tch...@cs.colorado.edu
"Will Hack Perl for Fine Food and Fun"
Boulder Colorado 303-444-3212
Benjamin Z. Goldsteen
As Keynes said, "We'll all be dead in the long run."
However, the question is if the people who work on Linux (the
core) are concerning themselves greatly with security or reliability or
networking or some_other_nifty_idea. This combined with the full
source in the hands of more people (than say AT&T SVR4)...
Don't take these notices as a personal attack on Linux. Most
stuff we use wasn't designed with security in mind. People should,
however, know exactly they are using before they decide to move their
accounting to the PC with free OS connected to the Internet.
--
Benjamin Z. Goldsteen
Olaf Titz
> Supposedly
> linux also has the shared library security problems that have plagued other
> UNIXes.
AFAIK, the Linux shared libraries use a hardwired library path and
therefore don't suffer the Sun library problem.
> Linux was never meant to be a secure OS, and it shouldn't be treated
> as such.
Replace "Linux" with "Un*x" (generic term) and you're (a bit) correct.
Many aspects of security are not part of the Un*x design, on which
Linux is built, other (such as user/group based file permissions) work
well just as designed. (The days you could run Linux only as root are
long, long gone. I suppose the Linux kernel is *more* secure than the
average Un*x implementation. The problems arise with broken
distributions - programs that don't fit are shipped together and thus
create holes even if the programs in itself would be secure. rshd is a
prime example - you simply can't fit shadowed and non-shadowed logins
on the same box...)
> With the widespread distribution of its source, people with a little
> initiative could find holes rather easily I'd say.
Right. But with the widespread distribution of source, finding the
bugs implies fixing them. So the system gets *more* secure.
Olaf
--
olaf titz o ol...@bigred.ka.sub.org praetorius@irc
comp.sc.student _>\ _ s_t...@ira.uka.de LINUX - the choice
karlsruhe germany (_)<(_) uk...@dkauni2.bitnet of a GNU generation
what good is a photograph of you? everytime i look at it it makes me feel blue
Timothy Newsham
>new...@wiliki.eng.hawaii.edu (Timothy Newsham) writes:
>
>>In article <2dm11j...@life.ai.mit.edu> l...@gnu.ai.mit.edu (laz) writes:
>
>>>UNIXes. Linux was never meant to be a secure OS, and it shouldn't be treated
>>>as such. With the widespread distribution of its source, people with a little
>>>initiative could find holes rather easily I'd say.
>
>>This will (in the long run) make linux more secure, not a less secure
>>environmen.
>
>core) are concerning themselves greatly with security or reliability or
>networking or some_other_nifty_idea. This combined with the full
>source in the hands of more people (than say AT&T SVR4)...
I simply argue that linux will become more secure as a result of the source
being available, not less secure. I dont argue that it will ever become
a "secure" operating system. Of course if the authors of various new
utilities and new kernel features keep adding holes to the system the
system will always have a low level of security, but with so many people
looking over these sources at least a few of them will be found out
quickly and closed. How does this compare to other operating systems?
I think the amount of time it takes for a hole to surface and how long
the hole can be kept a secret after being found is related to how available
to sources are.
>Benjamin Z. Goldsteen
Jozsef Hollosi
Hi,
I read some references to hand-held authenticators to provide challange-based
logins for remote users. However, I couldn't figure out who sells them.
Can anyone send me some phone numbers or other advice?
Thanks a lot,
Jozsef
<hol...@sbcm.com>
Greg Patten
>In article <1993120213...@an-teallach.com>
> gt...@an-teallach.com (Graham Toal) doodled:
>[Linux shadow passwd hole sacrificed to line eater]
>> OUCH!!! I thought 'No, can't apply to me, I have quite a recent Linux
>> here (like maybe 3 months old). It did... and would have given
>> *anyone* root access to a machine on our net and the ability to hop to
>> any other machine relatively easily :-(
>Coo, makes me glad that I'm not running shadow passwords on my PC on my
>desk.. How wisespread is the use of shadow passwords on Linux ?
Very widespread as a great many users have installed SLS
releases which was the purveyor of this BIG hole. I believe
early Slackware releases (due to it's being based on SLS)
had these problems too.
Another good one was the world writable root directory.
--
Greg Patten
gr...@loose.apana.org.au
Timothy Newsham
>security bug du jour. Unlike UNIX vendors, you have a direct path to the
>authors and to the maintainers of the free UNIX products.
Why is this true? Why do authors working for free care for their customers
more than vendors? Why is there a need for an organization like CERT to
act as a go between?
> -Ed
Edward DeHart
>
>I have linux, 386bsd, bsdi, dell, UnixWare, and SCO at this site. I also
>have a full-time job programming. I can't afford the time to wade through
>another 20 newsgroups to follow everything that's said on the groups for
>all these systems in the hope of spotting something I need to know about
>their security. Comp.security.{misc|unix} is the place to announce problems
>like that; that's what the crossposting mechanism was invented for. If it
>hadn't have been for hobbit having the sense to tell us, I'd never have
>known about that *nasty nasty nasty* hole. (I used to rely on CERT posting
>announcements of such problems, but now I know better. If my understanding
>of CERT is correct, I don't ever expect to see any announcements of holes
>in free OS's that don't also exist in proprietary ones...)
If we're alerted to a problem, we will look into it. We have posted
CERT Advisories on free products in the past and will continue to do
so. We can not report on problems unless they have been reported to us.
The free versions of UNIX are changing quickly enough that tuning into your
favorite newsgroup sounds like a reasonable way to stay current on the
security bug du jour. Unlike UNIX vendors, you have a direct path to the
authors and to the maintainers of the free UNIX products. If CERT is
needed to help resolve a problem and/or to announce a security fix, please
contact us.
-Ed
Doug McLaren
Edward DeHart <e...@cert.org> wrote:
>If we're alerted to a problem, we will look into it. We have posted
>CERT Advisories on free products in the past and will continue to do
>so. We can not report on problems unless they have been reported to us.
>The free versions of UNIX are changing quickly enough that tuning into your
>favorite newsgroup sounds like a reasonable way to stay current on the
>security bug du jour. Unlike UNIX vendors, you have a direct path to the
>authors and to the maintainers of the free UNIX products. If CERT is
>needed to help resolve a problem and/or to announce a security fix, please
>contact us.
Y'all were alerted about the in.rshd hole that existed in many (most?)
installed Linux systems, given an idea of how prevalent it was (quite
prevalent), and told that it was being abused. In addition, y'all
were told how to reproduce it, how to close it up right away, and also
told how to fix it right. At least I told y'all all this. I tend to
believe other people did as well.
I don't expect y'all to post about every little security hole that
there is (especially with something that changes as fast as Linux!),
but don't make it sound like y'all weren't told about it :)
--
dou...@utpapa.ph.utexas.edu
"Anarchy means having to put up with things that really piss you off."
Nathan Sidwell
: > -Ed
With free stuff, someone's personal reputation is on the line. With comercial
stuff, the vendor has already got the money, and has to supply the fix for free.
With noone's personal reputation at stake (only the company's), there is more
tendancy to bounce the problem. (IMHO)
nathan
--
Nathan Sidwell INMOS UK | | nat...@pact.srf.ac.uk
Valdis Kletnieks
Timothy:
This is mostly due to the fact that an author of freeware can just
hack a program, put a "hold harmless" copyright clause on it, and
park it for anonymous FTP.
On the other hand, commercial vendors are expected to do things like
testing the change, documenting the change, regression testing the
change to make sure it doesn't break anything else, check the source
code quality to make sure that programming standards are followed so
the next programmer who touches the code can figure out what's going
on. Then you get to do problem tracking, making sure that the fix
makes it into the next release, send the fix over to software packaging
so that they can make 100,000 CD-roms or 8mm tapes or what-have-you for
shipment to all your customers.
I suppose we *COULD* go back to the days when Unix was shipped as
an RL05 disk pack and a note that said "Have fun - DMR".
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Edward DeHart
I wouldn't come to the same conclusion as you about who cares more for whom.
For most freeware products it is just easier to communicate directly with the
people working on the project. In this case, you don't need help from
us. In larger organizations, it is harder for an individual to locate
the person or group within the vendor that will provide help. This is
one of the areas that CERT or other computer security response teams can
help.
Don't think of CERT as a "go between". If you have a relationship with
a vendor, by all means, contact them directly. We ask that you CC: us so
that we can follow the activity and, if needed, send out an advisory. We
have developed contacts with vendors that helps us to expedite problem
resolution. If you don't have a good contact, we can help in this area.
-Ed
Greg Patten
>new...@wiliki.eng.hawaii.edu (Timothy Newsham) writes:
Excuse my ignorance but how has this got anything to do with Linux
at all? The problem that you people are talking about was in how
Peter (the guy that did the SLS distibution and who has since been
flamed out of all existance) didn't compile in shadow support for
some important progams (like rsh) and didn't have something (like
a '*') in the second field of the distributed /etc/passwd.
Believe me, that's not the only problem with the SLS distribution(s)
and he refuses now to fix any of the bugs.
Again what has this actually got to do with linux as such (as
opposed to what I think is a very problematic distribution)?
--
Greg Patten
gr...@loose.apana.org.au
Christopher Samuel
In article <2e2ve6$l...@solaris.cc.vt.edu> of comp.security.unix,
val...@black-ice.cc.vt.edu (Valdis Kletnieks) doodled:
> I suppose we *COULD* go back to the days when Unix was shipped as an
> RL05 disk pack and a note that said "Have fun - DMR".
Hey, sounds like a great idea to me, if the sources are included I'd
be happy! Say goodbye to Colonel Bloat (think about it).. :-)
mumble mumble, ultrix, mumble, braindead, mumble mumble, sunos, mumble,
YP/DNS, mumble, AIX, mumble, man: command not found, mumble....
John F. Woods
>>Why is this true? Why do authors working for free care for their customers
>>more than vendors? Why is there a need for an organization like CERT to
>>act as a go between?
>hack a program, put a "hold harmless" copyright clause on it, and
>park it for anonymous FTP.
>On the other hand, commercial vendors are expected to do things like
>testing the change, documenting the change, regression testing the
>change to make sure it doesn't break anything else, check the source
>code quality to make sure that programming standards are followed so
>the next programmer who touches the code can figure out what's going on.
On the other other hand, commercial vendors usually just stick a "NO
WARRANTY OF MERCHANTABILITY" label on their copyright page and tell you
to "see Figure 1." :-)
Jeff Stehman
>Excuse my ignorance but how has this got anything to do with Linux
>at all? The problem that you people are talking about was in how
>Peter (the guy that did the SLS distibution and who has since been
>flamed out of all existance) didn't compile in shadow support for
>some important progams (like rsh) and didn't have something (like
>a '*') in the second field of the distributed /etc/passwd.
So how secure is Linux itself? If I pulled it down from one of the
primary sources and built it myself, would it be reasonable to use a
Linux box as, say, an internet firewall (meaning I would be anal on
all the file perms, passwords, etc., and drop the usual barrage of
public domain security packages on it, then openly insult crackers in
general so that they would test my security for me)? Long time
administrators of Linux, would you be comfortable doing that?
--
Jeff Stehman
James Bonfield
> Jeff Stehman (ste...@panix.com) wrote:
> : So how secure is Linux itself? If I pulled it down from one of the
> : primary sources and built it myself, would it be reasonable to use a
> : Linux box as, say, an internet firewall (meaning I would be anal on
> : all the file perms, passwords, etc., and drop the usual barrage of
> : public domain security packages on it, then openly insult crackers in
> : general so that they would test my security for me)? Long time
> : administrators of Linux, would you be comfortable doing that?
>
> Linux is as secure as you want to make it.
That's a pretty simplistic answer! You can never have a system 100% secure,
but that's what I want...
My personaly views on Linux are that once you've tested for all the normal
bugs (I know - not easy as we usually only hear of patches and not the bugs
themselves) then Linux is just as secure as any other system. In this I mean
that they both have all the holes publically known fixed, and an unknown
quantity of lesser known bugs. Proving linux to be less secure than the other
OSes at this point becomes tricky, and probably nearly impossible.
I've only had my Linux system for a short while, and as it's a standalone
machine that only I use I haven't ran any security checks on it. (Nevertheless
I've still gone through chowning all those bin files/directories. Plus I
grabbed the mcc distrib which doesn't have shadow passwords.) Hence don't
misinterpret this message as saying that I have checked for all the known
holes and verified them not there.
Linux is also confused in it's many distribution guises. My solution for this
was to grab the smallest, recompile the out of date bits, and add on missing
pieces when I noticed I needed them. This way I know my system much better
than if I'd installed (say) SLS. The Linux kernel is of pretty much course
common to all.
James
Brian McCauley
There are some subtle security holes in the /proc fs - please *DO*NOT*
follow-up on this statement the matter has been done to death - if you
are interested read the c.o.l.announce/c.o.l.d archives. I would
(weakly) advise agianst using /proc on a firewall system. IMHO for
systems other than dedicated firewalls the benefits on /proc outweigh
the risks.
There is also a massive security hole (no su authority needed to
install modules) in the version of modules that I've got but I belive
it's fixed in the current/next version. All a cracker needs to is
install an unchecked setuid() system call any he's away.
The console device driver also has security holes allowing a
determined cracker to redefine your keyboard. Not that this can
usually be used to do anything more than cause damage to the system -
it would not be likely to compomise the firewall.
Otherwise appart from the odd stupidity in the SLS distribution (as
quoted above) the system is reasonably safe.
--
\\ ( ) No Bullshit! | Email: B.A.Mc...@bham.ac.uk
. _\\__[oo from | Phones: +44 21 471 3789 (home)
.__/ \\ /\@ /~) /~[ /\/[ | +44 21 627 2171 (voice) 2175 (fax)
. l___\\ /~~) /~~[ / [ | PGP-fp: D7 03 2A 4B D8 3A 05 37
# ll l\\ ~~~~ ~ ~ ~ ~ | A1 93 FE EA BE E3 2A 91
###LL LL\\ (Brian McCauley) | More: finger b...@wcl-rs.bham.ac.uk
Kai Harrekilde-Petersen
b...@wcl-rs.bham.ac.uk (Brian McCauley) writes:
There is also a massive security hole (no su authority needed to
install modules) in the version of modules that I've got but I belive
it's fixed in the current/next version. All a cracker needs to is
install an unchecked setuid() system call any he's away.
I can add that in the `modules' that comes with ftape-0.9.7, you cannot
install a module without root permissions. However, an `unlock' utility is
provided so that you *can* install modules with having to su (this is nice
for development)
Kai Harrekilde-Petersen
Paul C Leyland
I suppose we *COULD* go back to the days when Unix was shipped as
an RL05 disk pack and a note that said "Have fun - DMR".
Oh. We got a 1/2" tape; three ring binders and a note which said "Good
luck!" They must have changed the distribution mechanism between our
two kits.
Paul
--
Paul Leyland <p...@oxford.ac.uk> | Hanging on in quiet desperation is
Oxford University Computing Service | the English way.
13 Banbury Road, Oxford, OX2 6NN, UK | The time is gone, the song is over.
Tel: +44-865-273200 Fax: +44-865-273275 | Thought I'd something more to say.
Finger p...@black.ox.ac.uk for PGP key |
Linus Torvalds
And in the modules patches that I used (yup, it's official as of the
next release), I removed even this feature - I don't see any real reason
for it (use a suid module-loader if you want to be unsecure, but I think
adding "de-security" features to the kernel proper is silly). So you
definitely have to be root to add/delete a module.
As to the /proc filesystem: it does open some security problems that are
hard to really fix without feature loss. I'd agree that if you are
really security-conscious you'd probably better not mount the proc
filesystem.
Linus
Joel M. Hoffman
>As to the /proc filesystem: it does open some security problems that are
>hard to really fix without feature loss. I'd agree that if you are
>really security-conscious you'd probably better not mount the proc
>filesystem.
>
> Linus
So let's also be careful not to add anything to Linux that absolutely
depends on /proc. The most common use of /proc (I think) is
proc-based top, w, and friends, but there are also kmem versions of
these. Do we have anything else so far the needs /proc?
-Joel
(jo...@wam.umd.edu)
--
-----------------------------------------------------------------------------
|_|~~ Germany, Europe. 1943. "The diameter of the bomb was 30 centimeters,
__|~| 16 Million DEAD. and the diameter of its destruction, about 7
meters, and in it four killed and 11 wounded.
cnc Bosnia, Europe. 1993. And around these, in a larger circle of pain
cnc HOW MANY MORE? and time, are scattered two hospitals and one
cemetery. But the young woman who was buried in
the place from where she came, at a distance of more than
than 100 kilometers, enlarges the circle considerably. And the
lonely man who is mourning her death in a distant country incorporates
into the circle the whole world. And I won't speak of the cry of the orphans
that reaches God's chair and from there makes the circle endless and godless."
-----------------------------------------------------------------------------
Tell Clinton to stop the genocide: pres...@whitehouse.gov
Christopher Samuel
jo...@rac3.wam.umd.edu (Joel M. Hoffman) doodled:
> So let's also be careful not to add anything to Linux that absolutely
> depends on /proc. The most common use of /proc (I think) is proc-based
> top, w, and friends, but there are also kmem versions of these. Do we
> have anything else so far the needs /proc?
I believe the Linux implimentation of the RFC931 daemon requires the
/proc support given in the Net2debugged code.
Patrick J. Volkerding
>In article <1993Dec12.1...@excaliber.uucp> of comp.security.unix,
> jo...@rac3.wam.umd.edu (Joel M. Hoffman) doodled:
>
>> So let's also be careful not to add anything to Linux that absolutely
>> depends on /proc. The most common use of /proc (I think) is proc-based
>> top, w, and friends, but there are also kmem versions of these. Do we
>> have anything else so far the needs /proc?
>
>I believe the Linux implimentation of the RFC931 daemon requires the
>/proc support given in the Net2debugged code.
>
If you're worried about /proc, but you still need it, there's no reason
why you can't "chmod 550 /proc" it after it gets mounted. Run the
daemons, w, ps and other programs that need to see /proc with sufficient
privileges to access it.
See how easy it is to patch these holes? :^)
---
Patrick Volkerding
volk...@mhd1.moorhead.msus.edu
Alan Cox
> jo...@rac3.wam.umd.edu (Joel M. Hoffman) doodled:
>
>> So let's also be careful not to add anything to Linux that absolutely
>> depends on /proc. The most common use of /proc (I think) is proc-based
>> top, w, and friends, but there are also kmem versions of these. Do we
>> have anything else so far the needs /proc?
>
>I believe the Linux implimentation of the RFC931 daemon requires the
>/proc support given in the Net2debugged code.
>
Indeed.
#mkdir /kmem/proc
#chown root.kmem /kmem
#chmod 770 /kmem
#ln -s /kmem/proc /proc
#mount -t proc /proc /proc
#chgrp kmem pidentd ps w uptime
#chmod 2711 pidentd ps w uptime
etc...
James W Abendschan
>hard to really fix without feature loss. I'd agree that if you are
>really security-conscious you'd probably better not mount the proc
>filesystem.
I have read that this has been discussed before, so I apologize if I'm
asking an old question, but what exactly is the problem in using /proc?
I ask because I run Linux with a dedicated dialin, and I also have a friend
who will soon be putting a Linux box on the net. Obviously, we'd like
to avoid any security problems :-)
Any pointers would be appreciated
James
PS; Thanks for Linux. :-) It's a very nice piece of work <clap clap>
--
"And so the play necessitates / That all you boys participate
In fierce competition to eliminate / Each other." -- I.A.
Drew Eckhardt
James W Abendschan <j...@sunset.cse.nau.edu> wrote:
>In article <2ef8bt$9...@klaava.Helsinki.FI> torv...@klaava.Helsinki.FI (Linus Torvalds) writes:
>>As to the /proc filesystem: it does open some security problems that are
>>hard to really fix without feature loss. I'd agree that if you are
>>really security-conscious you'd probably better not mount the proc
>>filesystem.
>
>I have read that this has been discussed before, so I apologize if I'm
>asking an old question, but what exactly is the problem in using /proc?
It depends on how paranoid you want to be -
Paranoid - ps, either proc or kmem based, is a security hole since it
lets users see the commands other users are running. /proc
is a problem since it tells users what the routing looks like,
what commands users are running, what directories they are in,
etc.
Sane - there's no problem.
Brian McCauley
>>I have read that this has been discussed before, so I apologize if I'm
>>asking an old question, but what exactly is the problem in using /proc?
> lets users see the commands other users are running. /proc
> is a problem since it tells users what the routing looks like,
> what commands users are running, what directories they are in,
> etc.
>
>Sane - there's no problem.
Actually the fact that /proc allows access to files in inaccesible
directories has, in previous discussions, always been considered the
main security hole in /proc. It's not a big hole but it's there - so
if a user relies on denying other users rx access to a directory in
order to keep her files safe then she's in trouble.
Malcolm Beattie
It's actually a bit more subtle than this. For example
the /proc/pid/fd directory gives you access to the currently
open file descriptors of a process and it is sometimes not
clear what the permissions on these ought to be. If I
remember rightly, Linus came up with an example of a suid
program which would go through various opening/chmoding/chowning
and suiding steps and end up giving the user access to the
contents of an open file descriptor with data intended to be
hidden from the user. I can't remember the details but there
are some interesting problems to sort out if you want to
make the /proc filesystem maximally useful but still secure.
--Malcolm
--
Malcolm Beattie <mbea...@black.ox.ac.uk>
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee
Marc J. Fraioli
Drew Eckhardt <dr...@kinglear.cs.colorado.edu> wrote:
>Paranoid - ps, either proc or kmem based, is a security hole since it
> lets users see the commands other users are running. /proc
> is a problem since it tells users what the routing looks like,
> what commands users are running, what directories they are in,
> etc.
So this is a "problem" with any Unix which includes a /proc filesystem,
not just Linux, right? Or is there more to it?
--
Marc Fraioli | The opinions expressed above may
m...@clark.net | disintegrate if exposed to bright
| light.
Malcolm Beattie
>In article <2enufo$c...@explorer.clark.net>, m...@clark.net (Marc J. Fraioli) says:
>+---------------
>| In article <CI2Ho...@colorado.edu>,
>| Drew Eckhardt <dr...@kinglear.cs.colorado.edu> wrote:
>| >Paranoid - ps, either proc or kmem based, is a security hole since it
>| > lets users see the commands other users are running. /proc
>| > is a problem since it tells users what the routing looks like,
>| > what commands users are running, what directories they are in,
>| > etc.
>|
>| So this is a "problem" with any Unix which includes a /proc filesystem,
>| not just Linux, right? Or is there more to it?
>
>Linux's /proc has a different implementation (and substantially mroe
>functionality) than other /proc implementations (in particular, SVR4's).
>To be specific: you use ioctl()s on a process "file", as opposed to there
>being a process directory, and you can't do the ioctl()s if you can't open the
>process "file". (Arguably, someone could modify Linux to do C2-style
>restriction of permissions on directories to resolve this.) And most other
>/proc implementations don't also provide other system information (such as the
>network information).
>
>The *big* hole is /proc/<pid>/fd, though. I'm kind of enamored of the idea of
>restricting this to root and the owning uid; /proc/self/fd is sufficient for
>most uses (and is essentially the same as /dev/fd on V9). But I'm not real
>clear on what, if anything, this would break.
/proc/pid/fd does need careful thought if it's going to be
secure but useful. Even if you restrict to root and the owning
uid, what about if a suid program opens a sensitive file on behalf
of a user and then sets real and effective uids back to that of
the user? Do you let the user now have access to that file
descriptor? I doubt the program will be expecting it. Now,
what happens if the program exec's another program, passing it
the file descriptor? Do you let the user get at it now? How do you
tell the difference? Maybe taint the descriptor if it's ever opened
by a process with euid != ruid or egid != rgid and never reduce
permissions until closure? Can you pass an open file descriptor
down an AF_UNIX socket with Linux yet? (I'm on an old-but-stable
0.99pl8 at home where you still can't.) If so, how do you regulate
permissions on those file descriptors? I think this has the
makings of becoming quite an interesting security-related thread.
Casper H.S. Dik
>The *big* hole is /proc/<pid>/fd, though. I'm kind of enamored of the idea of
>restricting this to root and the owning uid; /proc/self/fd is sufficient for
>most uses (and is essentially the same as /dev/fd on V9). But I'm not real
>clear on what, if anything, this would break.
Much worse is the /proc/<pid>/cwd directory. If you are in an
unprotected subdirectory of a protected directory, anyone can get
into that directory.
(such directories are not uncommon, e.g., people have an umask of 022
but restrict access to files by protecting some directories)
I'm not sure that linux /proc is more powerful than SysVr4s.
Is it possible in Linux to open a single file and get access
to the entire address space? I saw only a set of mmap'ed objects.
Casper
Frank Lofaro
>In article <2enufo$c...@explorer.clark.net>, m...@clark.net (Marc J. Fraioli) says:
>+---------------
>| Drew Eckhardt <dr...@kinglear.cs.colorado.edu> wrote:
>| >Paranoid - ps, either proc or kmem based, is a security hole since it
>| > lets users see the commands other users are running. /proc
>| > is a problem since it tells users what the routing looks like,
>| > what commands users are running, what directories they are in,
>| > etc.
>|
>| So this is a "problem" with any Unix which includes a /proc filesystem,
>| not just Linux, right? Or is there more to it?
>
>Linux's /proc has a different implementation (and substantially mroe
>functionality) than other /proc implementations (in particular, SVR4's).
>To be specific: you use ioctl()s on a process "file", as opposed to there
>being a process directory, and you can't do the ioctl()s if you can't open the
>process "file". (Arguably, someone could modify Linux to do C2-style
>restriction of permissions on directories to resolve this.) And most other
>/proc implementations don't also provide other system information (such as the
>network information).
>
>restricting this to root and the owning uid; /proc/self/fd is sufficient for
>most uses (and is essentially the same as /dev/fd on V9). But I'm not real
>clear on what, if anything, this would break.
>
This is a good idea. Let me add though, restrict it to only work for root and
users who share both the same uid AND euid of the process owning the file
descriptors, so people can't for example, use /proc/fd to play with the modem
on a setup where kermit is setgid uucp.
James W Abendschan
>The *big* hole is /proc/<pid>/fd, though. I'm kind of enamored of the idea of
>restricting this to root and the owning uid; /proc/self/fd is sufficient for
>most uses (and is essentially the same as /dev/fd on V9). But I'm not real
>clear on what, if anything, this would break.
As an ordinary user, I cd'd to /proc/3 [which is /etc/update's PID], then
did an ls -l fd:
% cd /proc/3
% ls -l fd
ls: fd: Permission denied
fd is mode 500. I did this on another non-root process and got the same
results. [This is pl12, btw.]
Am I missing something?
James
Mike Horwath
/proc filesystem.
ALmost everything that is critical is already setup so that a normal user
can NOT cause problems with processes they do not themselves own.
I do agree on the problem with /proc/<pid>/cwd though, since someone might
have a protected directory, I am going to have to see if protecting the
directory itself will be enough to stop this.
Besides the /proc/<pid>/cwd problem, what other things are wrong?
Someone mentioned /proc/<pid>/fd/*, but even though I know what file
descriptors are listed there, I can't read or write to them getting
a permission denied message.
--
Mike Horwath IRC: Drechsau BBS: Drechsau LIFE: lover
ro...@jacobs.mn.org drec...@jacobs.mn.org
Jacob's Ladder 612-588-0201 UUCP, UseNet, Linux files, BBS
QEII
>In article <1993Dec16....@black.ox.ac.uk>, mbea...@black.ox.ac.uk (Malcolm Beattie) says:
>+---------------
>| In article <1993Dec16.0...@kf8nh.wariat.org> b...@kf8nh.wariat.org (Brandon S. Allbery) writes:
>| >Linux's /proc has a different implementation (and substantially mroe
>| >functionality) than other /proc implementations (in particular, SVR4's).
>How is this different from:
># cat insecure.c
>#include <stdio.h>
>int
>main(int argc, char **argv)
>{
> FILE *fp;
> if (!(fp = fopen("/etc/passwd", "a")))
> {
> perror("/etc/passwd");
> return 1;
> }
> setuid(getuid());
> /* code here can now append anything it wants to /etc/passwd */
> return 0;
>}
># gcc -o insecure insecure.c
># chmod 4755 insecure
>It doesn't take /proc to do this; traditional mechanisms work just fine...
There are plenty of security of holes in UNIX. I won't
tell you any of them, you have to find them yourself.
My suggestion to the guy who asked. Don't worry you arn't safe.
Permissions in an OS prevent a bit of grief on an
multi-user system. They don't give you security, they save you
from a few of your own mistakes.
--
Proud owner of one of the first Hell Credit Cards.
"Spend all you want. You'll pay later."