> -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
subscribe
subscribe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
>
13 matches
Mail list logo
