> 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'
> 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'
GV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
>
>
> TPE does not prevent attackers from running /lib/ld-linux.so.2, but
> restricts them from mmaping files in /tmp (and some other dirs, of course).
> Since the question was about "execute permissions in /tmp", not
GV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
>
>
> TPE does not prevent attackers from running /lib/ld-linux.so.2, but
> restricts them from mmaping files in /tmp (and some other dirs, of course).
> Since the question was about "execute permissions in /tmp", not
> -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
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
> > directori
> -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:
> &g
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
> > directori
> 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
> 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
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 o
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 TMPD
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 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
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 o
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 TMPD
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 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 (depen
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 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
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 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 (depen
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 (depen
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 (depen
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 diffi
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 directo
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 writeab
> -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 u
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 abo
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 diffi
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 directo
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 writeab
> -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 u
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 abo
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 p
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 p
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
>
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, 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 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
> b
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 "/t
nal 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 Po
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
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 box
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 bei
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
> b
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 "/t
nal 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:
>
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
Desc
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 box
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 bei
52 matches
Mail list logo
