Looks that way. I guess I mis-interpreted the grsec docs
(and since I don't have a kernel compiled with TPE, I didn't
test it). It seems that it already does what I suggested it
do: not allow mmap with PROT_EXEC under certain conditions.
(You did make sure that this behaviour isn't
Looks that way. I guess I mis-interpreted the grsec docs
(and since I don't have a kernel compiled with TPE, I didn't
test it). It seems that it already does what I suggested it
do: not allow mmap with PROT_EXEC under certain conditions.
(You did make sure that this behaviour isn't
On Tue, Jul 15, 2003 at 09:38:45AM +0200, DEFFONTAINES Vincent wrote:
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the
code in them.
even if the user is a nobody that owns no files or
directories and
-Original Message-
From: Peter Cordes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 9:35 AM
To: [EMAIL PROTECTED]
Subject: Re: execute permissions in /tmp
On Tue, Jul 15, 2003 at 09:38:45AM +0200, DEFFONTAINES Vincent wrote:
On Sun, Jul 13, 2003 at 11:55:45PM
mmaping files in /tmp (and some other dirs, of course).
Since the question was about execute permissions in /tmp, not
restraining attackers from running /bin/sh, I tend to believe it
does indeed help.
Looks that way. I guess I mis-interpreted the grsec docs (and since I
don't have a kernel
On Tue, Jul 15, 2003 at 09:38:45AM +0200, DEFFONTAINES Vincent wrote:
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the
code in them.
even if the user is a nobody that owns no files or
directories and
-Original Message-
From: Peter Cordes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 9:35 AM
To: debian-security@lists.debian.org
Subject: Re: execute permissions in /tmp
On Tue, Jul 15, 2003 at 09:38:45AM +0200, DEFFONTAINES Vincent wrote:
On Sun, Jul 13, 2003
mmaping files in /tmp (and some other dirs, of course).
Since the question was about execute permissions in /tmp, not
restraining attackers from running /bin/sh, I tend to believe it
does indeed help.
Looks that way. I guess I mis-interpreted the grsec docs (and since I
don't have a kernel
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the
code in them.
even if the user is a nobody that owns no files or
directories and grsecurity, selinux or the like prevents
him/her to execute directly code from
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the
code in them.
even if the user is a nobody that owns no files or
directories and grsecurity, selinux or the like prevents
him/her to execute directly code from
On Mon, Jul 14, 2003 at 01:02:33AM -0400, bda wrote:
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the code in them. What
problem is noexec /tmp supposed to solve?
In the event that the machine gets popped (depending
On Mon, Jul 14, 2003 at 01:02:33AM -0400, bda wrote:
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the code in them.
What problem is noexec /tmp supposed to solve?
In the event that the machine gets popped (depending
On Mon, Jul 14, 2003 at 12:13:37PM +0100, David Ramsden wrote:
I'd like to agree.
noexec almost certainly better than nothing at all!
Only if it were obviously correct and cost nothing. In the case of noexec
on /tmp, it breaks things and so the small amount of obfuscation is not
worth it in
On Mon, Jul 14, 2003 at 12:23:01PM -0400, bda wrote:
I mount /tmp noexec and nosuid, and it's not broken anything on any of
my Debian machines (or *bsd) machines yet.
Apparently, you don't use debconf preconfiguration.
As for the ~/tmp or ~/.tmp commentary, I have no real opinion, but it
On Mon, Jul 14, 2003 at 01:44:21PM -0400, Phillip Hofmeister wrote:
On Mon, 14 Jul 2003 at 12:55:38PM -0400, Matt Zimmerman wrote:
On Mon, Jul 14, 2003 at 12:23:01PM -0400, bda wrote:
As for the ~/tmp or ~/.tmp commentary, I have no real opinion, but it
seems like it'd be a lot of work
-Original Message-
From: Matt Zimmerman
Sent: Sunday, 13 July, 2003 23:56
If the user can read files in /tmp, they can execute the code in
them. What problem is noexec /tmp supposed to solve?
Microsoft did a related thing a few years ago, they moved the TEMP directory
to the users
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the code in them.
even if the user is a nobody that owns no files or directories
and grsecurity, selinux or the like prevents him/her to execute
directly code from world writeable
If I may, both bastille and libpam-temp allow something similar for
`real users` ($TMP pointing to a temporary directory inside a user's
home)
but /tmp is used more often by programs, cron (or other automation
software, which would require trwxrwxrwx permissions and or doesn't
use) in a
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the code in them. What
problem is noexec /tmp supposed to solve?
In the event that the machine gets popped (depending on the vector of
attack), it makes it that much more
On Mon, Jul 14, 2003 at 01:02:33AM -0400, bda wrote:
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the code in them. What
problem is noexec /tmp supposed to solve?
In the event that the machine gets popped (depending
On Mon, Jul 14, 2003 at 01:02:33AM -0400, bda wrote:
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the code in them.
What problem is noexec /tmp supposed to solve?
In the event that the machine gets popped (depending
On Mon, Jul 14, 2003 at 12:13:37PM +0100, David Ramsden wrote:
I'd like to agree.
noexec almost certainly better than nothing at all!
Only if it were obviously correct and cost nothing. In the case of noexec
on /tmp, it breaks things and so the small amount of obfuscation is not
worth it in
On Mon, Jul 14, 2003 at 11:28:50AM -0400, Matt Zimmerman wrote:
Security by obscurity isn't security.
I disagree that it's security through obscurity. It's just another layer
of security, of making an attacker (theoretically) take that one extra
step, making them work just a little bit harder to
On Mon, 14 Jul 2003 at 12:55:38PM -0400, Matt Zimmerman wrote:
On Mon, Jul 14, 2003 at 12:23:01PM -0400, bda wrote:
As for the ~/tmp or ~/.tmp commentary, I have no real opinion, but it
seems like it'd be a lot of work to implement. :-)
Most of the work is adding support for the TMPDIR
On Mon, Jul 14, 2003 at 01:44:21PM -0400, Phillip Hofmeister wrote:
On Mon, 14 Jul 2003 at 12:55:38PM -0400, Matt Zimmerman wrote:
On Mon, Jul 14, 2003 at 12:23:01PM -0400, bda wrote:
As for the ~/tmp or ~/.tmp commentary, I have no real opinion, but it
seems like it'd be a lot of work
On Sun, Jul 13, 2003 at 01:33:52AM -0400, Noah L. Meyerhans wrote:
On Sat, Jul 12, 2003 at 11:43:02PM -0300, Peter Cordes wrote:
This is at least the third time this has come up that I remember. However,
absolute statements like *can not* get me thinking: Is there any any sort
of file
On Sat, 12 Jul 2003 at 09:34:16PM -0400, Noah L. Meyerhans wrote:
Basically, what it comes down to is that you *can not* prevent files
from being executed. Even if you remove the execute bits from /tmp/ls
in the above example, you'll still be able to run it.
I believe grsecurity ACLs will
On Sun, Jul 13, 2003 at 03:10:24PM -0400, Phillip Hofmeister wrote:
On Sat, 12 Jul 2003 at 09:34:16PM -0400, Noah L. Meyerhans wrote:
Basically, what it comes down to is that you *can not* prevent files
from being executed. Even if you remove the execute bits from /tmp/ls
in the above
-Original Message-
From: Matt Zimmerman
Sent: Sunday, 13 July, 2003 23:56
If the user can read files in /tmp, they can execute the code in
them. What problem is noexec /tmp supposed to solve?
Microsoft did a related thing a few years ago, they moved the TEMP directory
to the users
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the code in them.
even if the user is a nobody that owns no files or directories
and grsecurity, selinux or the like prevents him/her to execute
directly code from world writeable
If I may, both bastille and libpam-temp allow something similar for
`real users` ($TMP pointing to a temporary directory inside a user's
home)
but /tmp is used more often by programs, cron (or other automation
software, which would require trwxrwxrwx permissions and or doesn't
use) in a
On Sun, Jul 13, 2003 at 11:55:45PM -0400, Matt Zimmerman wrote:
If the user can read files in /tmp, they can execute the code in them. What
problem is noexec /tmp supposed to solve?
In the event that the machine gets popped (depending on the vector of
attack), it makes it that much more
On Sat, Jul 12, 2003 at 11:43:02PM -0300, Peter Cordes wrote:
This is at least the third time this has come up that I remember. However,
absolute statements like *can not* get me thinking: Is there any any sort
of file that can't be executed from /tmp? What about statically linked ELF
On Sun, Jul 13, 2003 at 01:33:52AM -0400, Noah L. Meyerhans wrote:
On Sat, Jul 12, 2003 at 11:43:02PM -0300, Peter Cordes wrote:
This is at least the third time this has come up that I remember.
However,
absolute statements like *can not* get me thinking: Is there any any sort
of
On Sat, 12 Jul 2003 at 09:34:16PM -0400, Noah L. Meyerhans wrote:
Basically, what it comes down to is that you *can not* prevent files
from being executed. Even if you remove the execute bits from /tmp/ls
in the above example, you'll still be able to run it.
I believe grsecurity ACLs will
On Sun, Jul 13, 2003 at 03:10:24PM -0400, Phillip Hofmeister wrote:
On Sat, 12 Jul 2003 at 09:34:16PM -0400, Noah L. Meyerhans wrote:
Basically, what it comes down to is that you *can not* prevent files
from being executed. Even if you remove the execute bits from /tmp/ls
in the above
I have a complaint/opinion/statement to express. It seems that every now
and then when I run 'apt-get upgrade' i get a lot of errors about Can't
exec /tmp/config.x: Permission denied at I like to keep my
Debian boxen nice and secure, so I 'chmod +t /tmp' to prevent temp files
from being
On Sat, Jul 12, 2003 at 09:22:45PM -0400, Jim Popovitch wrote:
I have a complaint/opinion/statement to express. It seems that every now
and then when I run 'apt-get upgrade' i get a lot of errors about Can't
exec /tmp/config.x: Permission denied at I like to keep my
Debian boxen nice
On Sat, Jul 12, 2003 at 09:34:16PM -0400, Noah L. Meyerhans wrote:
# cp /bin/ls /tmp/
# /lib/ld-linux.so.2 /bin/ls
^^^
Naturally I meant /tmp/ls on the second line there. I'm sure you
figured that out on your own, but just for the record...
noah
pgp0.pgp
Message-
From: Noah L. Meyerhans [mailto:[EMAIL PROTECTED] Behalf Of Noah L.
Meyerhans
Sent: Saturday, 12 July, 2003 21:34
To: [EMAIL PROTECTED]
Subject: Re: execute permissions in /tmp
On Sat, Jul 12, 2003 at 09:22:45PM -0400, Jim Popovitch wrote:
I have a complaint/opinion/statement
On Sat, Jul 12, 2003 at 10:37:24PM -0400, Jim Popovitch wrote:
Well now, that is interesting. You are absolutely correct about the sticky
bit. It is the noexec flag that this is happening with, and I agree that it
alone is not a total security solution. However, it is a piece of a much
On Sat, Jul 12, 2003 at 11:43:02PM -0300, Peter Cordes wrote:
This is at least the third time this has come up that I remember. However,
absolute statements like *can not* get me thinking: Is there any any sort
of file that can't be executed from /tmp? What about statically linked ELF
I have a complaint/opinion/statement to express. It seems that every now
and then when I run 'apt-get upgrade' i get a lot of errors about Can't
exec /tmp/config.x: Permission denied at I like to keep my
Debian boxen nice and secure, so I 'chmod +t /tmp' to prevent temp files
from being
On Sat, Jul 12, 2003 at 09:22:45PM -0400, Jim Popovitch wrote:
I have a complaint/opinion/statement to express. It seems that every now
and then when I run 'apt-get upgrade' i get a lot of errors about Can't
exec /tmp/config.x: Permission denied at I like to keep my
Debian boxen nice
On Sat, Jul 12, 2003 at 09:34:16PM -0400, Noah L. Meyerhans wrote:
# cp /bin/ls /tmp/
# /lib/ld-linux.so.2 /bin/ls
^^^
Naturally I meant /tmp/ls on the second line there. I'm sure you
figured that out on your own, but just for the record...
noah
pgph5wAJkMhjE.pgp
Message-
From: Noah L. Meyerhans [mailto:[EMAIL PROTECTED] Behalf Of Noah L.
Meyerhans
Sent: Saturday, 12 July, 2003 21:34
To: debian-security@lists.debian.org
Subject: Re: execute permissions in /tmp
On Sat, Jul 12, 2003 at 09:22:45PM -0400, Jim Popovitch wrote:
I have a complaint/opinion
On Sat, Jul 12, 2003 at 09:34:16PM -0400, Noah L. Meyerhans wrote:
On Sat, Jul 12, 2003 at 09:22:45PM -0400, Jim Popovitch wrote:
I have a complaint/opinion/statement to express. It seems that every now
and then when I run 'apt-get upgrade' i get a lot of errors about Can't
exec
On Sat, Jul 12, 2003 at 10:37:24PM -0400, Jim Popovitch wrote:
Well now, that is interesting. You are absolutely correct about the sticky
bit. It is the noexec flag that this is happening with, and I agree that it
alone is not a total security solution. However, it is a piece of a much
48 matches
Mail list logo
