On 2009-01-16, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote:
--nextPart7126651.dTOK38xoNi
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Friday 2009 January 16 04:13:10 Michael Loftis wrote:
--On January 16,
Hallo,
I manage a lot of debian servers and try to install often the updates.
So I had in mind my systems are well prepaired. (I follow also other
security rules ;-) )
But since some days I mull over a question: What happens if a user run
a selfcopy from a program with a security hole? I'm
--On January 16, 2009 10:31:35 AM +0100 Andreas Matthus
andreas.matt...@tu-dresden.de wrote:
Hallo,
I manage a lot of debian servers and try to install often the updates.
So I had in mind my systems are well prepaired. (I follow also other
security rules ;-) )
But since some days I mull
Le Fri, 16 Jan 2009 10:31:35 +0100,
Andreas Matthus andreas.matt...@tu-dresden.de a écrit :
Hallo,
I manage a lot of debian servers and try to install often the updates.
So I had in mind my systems are well prepaired. (I follow also other
security rules ;-) )
But since some days I mull
On Friday 2009 January 16 04:13:10 Michael Loftis wrote:
--On January 16, 2009 10:31:35 AM +0100 Andreas Matthus
andreas.matt...@tu-dresden.de wrote:
But since some days I mull over a question: What happens if a user run
a selfcopy from a program with a security hole? I'm afraid he can get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Boyd Stephen Smith Jr. wrote:
What about hardlinking the suid-root binaries to a hidden location, waiting
for a security hole to be found/fixed, and then running the old binary to
exploit the hole?
IIRC, a hard link is the same file called two
On Friday 2009 January 16 12:29:13 Johannes Wiedersich wrote:
Boyd Stephen Smith Jr. wrote:
What about hardlinking the suid-root binaries to a hidden location,
waiting for a security hole to be found/fixed, and then running the old
binary to exploit the hole?
IIRC, a hard link is the same file
--On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich
johan...@physik.blm.tu-muenchen.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Boyd Stephen Smith Jr. wrote:
What about hardlinking the suid-root binaries to a hidden location,
waiting for a security hole to be
Boyd Stephen Smith Jr. wrote:
What about hardlinking the suid-root binaries to a hidden location, waiting
for a security hole to be found/fixed, and then running the old binary to
exploit the hole? Does dpkg handle suid/sgid files so that this is
prevented?
Hi,
Having /home, /tmp,
On Friday 2009 January 16 14:45:44 Michael Loftis wrote:
--On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich
johan...@physik.blm.tu-muenchen.de wrote:
Boyd Stephen Smith Jr. wrote:
What about hardlinking the suid-root binaries to a hidden location,
waiting for a security hole to be
Boyd Stephen Smith Jr. wrote:
Did you mean this to go to the list? I've replied directly to you, but feel
free to repost my mail or part thereof to the list if you believe the
discussion could continue there.
Sorry, my fault.
On Friday 2009 January 16 13:03:53 you wrote:
Boyd Stephen
On Friday 2009 January 16 15:49:46 Repasi Tibor wrote:
Boyd Stephen Smith Jr. wrote:
On Friday 2009 January 16 13:03:53 you wrote:
Boyd Stephen Smith Jr. wrote:
What about hardlinking the suid-root binaries to a hidden location,
waiting for a security hole to be found/fixed, and then running
Hi,
On Fri, Jan 16, 2009 at 03:13:10PM -0600, Boyd Stephen Smith Jr. wrote:
On Friday 2009 January 16 14:45:44 Michael Loftis wrote:
[hardlinking (suid binaries in hope a vulnerability will be found)]
you can't do
it across drives,
Right, but the default partitioning puts /sbin /usr/sbin
On Friday 16 January 2009, Mike Dornberger mike.dornber...@gmx.de wrote
about 'Re: basically security of linux':
Hi,
just an addition: Often I've seen /home as a separate mount (mounted
nosuid,nodev,...) and /tmp as tmpfs, but then we have /var/tmp (which
can't be tmpfs, because it's purpose
In article 20090117002104.ga...@wolfden.dnsalias.net you wrote:
/tmp as tmpfs, but then we have /var/tmp (which can't
be tmpfs, because it's purpose is to retain the files even across reboots).
It is just supposed to hold larger data. No persistence in /var/tmp over
reboots required.
I
Bernd Eckenfels e...@lina.inka.de writes:
In article 20090117002104.ga...@wolfden.dnsalias.net you wrote:
/tmp as tmpfs, but then we have /var/tmp (which can't be tmpfs, because
it's purpose is to retain the files even across reboots).
It is just supposed to hold larger data. No persistence
16 matches
Mail list logo
