On 8/21/2005 10:54, Matthew Burgess wrote:
> ping.c:63 - "This program has to run SUID to ROOT to access the ICMP
> socket."
That's crazy. Normal pings shouldn't require root. Only changing payload
size or flooding or other such things should require it.
Netkit ping has this behavior. ...or
On Mon, Aug 22, 2005 at 12:03:49PM -0400, Jason Gurtz wrote:
> On 8/21/2005 10:54, Matthew Burgess wrote:
>
> > ping.c:63 - "This program has to run SUID to ROOT to access the ICMP
> > socket."
>
> That's crazy. Normal pings shouldn't require root.
IIRC, the standard kernel socket interface si
Jason Gurtz wrote:
On 8/21/2005 10:54, Matthew Burgess wrote:
ping.c:63 - "This program has to run SUID to ROOT to access the ICMP
socket."
That's crazy. Normal pings shouldn't require root. Only changing payload
size or flooding or other such things should require it.
Netkit ping has this
Andrew Benton wrote:
Jason Gurtz wrote:
On 8/21/2005 10:54, Matthew Burgess wrote:
ping.c:63 - "This program has to run SUID to ROOT to access the ICMP
socket."
That's crazy. Normal pings shouldn't require root. Only changing
payload
size or flooding or other such things should require
On 8/22/2005 12:39, Bryan Kadzban wrote:
> On Mon, Aug 22, 2005 at 12:03:49PM -0400, Jason Gurtz wrote:
>
>> That's crazy. Normal pings shouldn't require root.
>
> IIRC, the standard kernel socket interface simply has no way to send any
> kind of ICMP packet (echo-request included). Therefore, y
> Hmm, still think it's crazy. Maybe that's a missing feature in the
> kernel? Somehow I think that'll never see the light of day.
>
> I looked and my ping is setuid.
>
> -rwsr-xr-x1 root root15876 Sep 4 2001 /bin/ping*
Yep, it may be crazy, but that's how it is... Stops peo
Jason Gurtz wrote:
> On 8/22/2005 12:39, Bryan Kadzban wrote:
>
>>On Mon, Aug 22, 2005 at 12:03:49PM -0400, Jason Gurtz wrote:
>>
>>
>>>That's crazy. Normal pings shouldn't require root.
>>
>>IIRC, the standard kernel socket interface simply has no way to send any
>>kind of ICMP packet (echo-requ
Bruce Dubbs wrote:
Controlling access
through a well audited executable with suid privs is a much more secure
alternative.
Unless of course it happens to be inetutils-ping
(http://lists.gnu.org/archive/html/bug-inetutils/2005-07/msg00030.html) :-)
Matt.
--
http://linuxfromscratch.org/mailman
On 8/22/2005 13:16, Bruce Dubbs wrote:
> I think it would be a much greater security problem if sending icmp or
> opening raw sockets by non-root users was allowed.
Certainly raw sockets would be a huge risk, but I don't see how echo_reply
at a 1 per second rate or something is a problem. I guess
On 8/22/2005 13:25, Matthew Burgess wrote:
> Unless of course it happens to be inetutils-ping
> (http://lists.gnu.org/archive/html/bug-inetutils/2005-07/msg00030.html) :-)
Ouch!
~Jason
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubsc
Hi all,
With the GNOME-2.12 release due to be ready in a couple of weeks,
I'd like to propose a couple of new packages that need to be added
to the BLFS book.
It is my understanding that GNOME-2.12 will require the 2.8 branch
of GTK+. This is a brand-new release and now requires the Cairo
graphic
On Aug 22, 2005, at 12:33 PM, Jason Gurtz wrote:
Certainly raw sockets would be a huge risk, but I don't see how
echo_reply
at a 1 per second rate or something is a problem.
Except you'd have to add a kernel interface just to send ICMP echo
requests, along with whatever options you want to
Hi folks.
Does anyone know why shared libraries need the execute bit set on them?
My most recent build (gcc4-based) has most[1] *.so files installed
with 755 permissions. As it's so consistent, I'm assuming there is a
reason for them to be executable. Thanks to Tarek Ghaleb and Andrew
Bent
Matthew Burgess wrote:
> Hi folks.
>
> Does anyone know why shared libraries need the execute bit set on them?
> My most recent build (gcc4-based) has most[1] *.so files installed with
> 755 permissions. As it's so consistent, I'm assuming there is a reason
> for them to be executable. Thanks t
On Mon, 22 Aug 2005, Matthew Burgess wrote:
Hi folks.
Does anyone know why shared libraries need the execute bit set on them? My
most recent build (gcc4-based) has most[1] *.so files installed with 755
permissions. As it's so consistent, I'm assuming there is a reason for them
to be execut
Ken Moffat wrote these words on 08/22/05 15:06 CST:
>>[1] Exceptions being: /lib/libproc-3.2.5.so (555), /usr/lib/libc.so (644),
>>/usr/lib/libpthread.so (644), /usr/lib/preloadable_libintl.so (644), and
>>Perl's modules (555)
>
> /usr/lib/lib{c,pthread}.so aren't libraries, they are ld scrip
Matthew Burgess wrote:
> Does anyone know why shared libraries need the execute bit set on them?
AFAICT they don't need it (except of course libc.so.6 and ld-linux.so.2).
Debian ship a whole distro with the shared libs all 644 (apart from those
2 aforementioned libs).
IMHO the current practice
On 8/23/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Hi folks.
>
> Does anyone know why shared libraries need the execute bit set on them?
> My most recent build (gcc4-based) has most[1] *.so files installed
> with 755 permissions. As it's so consistent, I'm assuming there is a
> reason for
On Mon, Aug 22, 2005 at 01:33:37PM -0400, Jason Gurtz wrote:
>
> Certainly raw sockets would be a huge risk, but I don't see how echo_reply
> at a 1 per second rate or something is a problem. I guess a non-root user
> could flood a host just as easily with some standard TCP packet--HTTP GET
> for
19 matches
Mail list logo
