On Thu, Dec 6, 2012 at 5:46 AM, matthew green m...@eterna.com.au wrote:
I've reread the whole thread but I don't understand how fch* and fexec*
differ.
As far as I can see all they cause the same sort of problems.
So, a solution should be the same for all of them.
AFAIK (i didn't write a
On Wed, 5 Dec 2012 20:42:32 +
David Holland dholland-t...@netbsd.org wrote:
That may be, but it's still true of file descriptors. Traditionally
they're capabilities, and I really don't like the idea of rearranging
that arbitrarily and inconsistently.
I think to do this correctly, exec
Date:Wed, 5 Dec 2012 03:02:09 +
From:Roland C. Dowdeswell el...@imrryr.org
Message-ID: 20121205030209.gv1...@mournblade.imrryr.org
| Let's not lose sight of the fact that chroot can most certainly
| compromise security if used improperly
Yes, of course, there
On Tue, Dec 04, 2012 at 11:42:04PM +0700, Robert Elz wrote:
First, I'm not sure it is really worth fixing at all, this doesn't
seem to be a particularly big problem in reality. But, that said,
if a file exists, has x permission, and there's something executable
behind it, then exec should
On Tue, Dec 4, 2012 at 7:42 PM, Robert Elz k...@munnari.oz.au wrote:
Even chroot isn't a problem, unless you're tempted to view it as some
kind of security mechanism. It really isn't
...
If true compartmentalisation is wanted for security purposes, we would
need something approaching true
On Wed, Dec 05, 2012 at 05:17:25PM +0300, Aleksey Cheusov wrote:
On the other hand if we generalize improvements of fchdir(2) and fchroot(2)
(I mean EPERM if the current working directory is not at or under the new
root directory), that is reimplement them with a help of kauth(9) we
will be
On Wed, Dec 5, 2012 at 5:21 PM, Thor Lancelot Simon t...@panix.com wrote:
On Wed, Dec 05, 2012 at 05:17:25PM +0300, Aleksey Cheusov wrote:
On the other hand if we generalize improvements of fchdir(2) and fchroot(2)
(I mean EPERM if the current working directory is not at or under the new
This system call embodies a fairly fundamental shift away from the
Unix model that object permissions are checked when you get a handle
to an object -- not when you use that handle.
Actually, I think that's true only of file descriptors. I'm having
trouble thinking of any other case where
On Wed, Dec 5, 2012 at 6:17 AM, Aleksey Cheusov cheu...@tut.by wrote:
On Tue, Dec 4, 2012 at 7:42 PM, Robert Elz k...@munnari.oz.au wrote:
Even chroot isn't a problem, unless you're tempted to view it as some
kind of security mechanism. It really isn't
...
If true compartmentalisation
On Wed, Dec 05, 2012 at 01:08:14PM -0500, Mouse wrote:
This system call embodies a fairly fundamental shift away from the
Unix model that object permissions are checked when you get a handle
to an object -- not when you use that handle.
Actually, I think that's true only of file
On Wed, Dec 05, 2012 at 08:39:55AM -0500, Thor Lancelot Simon wrote:
I also think we need to check, for all the fch*, fexec* syscalls:
* permissions both retained from the file's open and at the time
of use
I don't think this is necessary, any more than it is for read and
* whether the name in question is within the process' current
root (forbidding fchdir and fchroot otherwise).
Definitely.
I'm actually not convinced this is so obviously a good thing.
I see an analogy between root directories and UIDs. We have chroot(),
and we have setuid() - but
On Wed, Dec 05, 2012 at 04:03:40PM -0500, Mouse wrote:
* whether the name in question is within the process' current
root (forbidding fchdir and fchroot otherwise).
Definitely.
I'm actually not convinced this is so obviously a good thing.
I see an analogy between root
Date:Wed, 5 Dec 2012 08:39:55 -0500
From:Thor Lancelot Simon t...@panix.com
Message-ID: 20121205133955.ga12...@panix.com
| I strongly disagree. This system call embodies a fairly fundamental
| shift away from the Unix model ...
I know that this thread is
I've reread the whole thread but I don't understand how fch* and fexec*
differ.
As far as I can see all they cause the same sort of problems.
So, a solution should be the same for all of them.
AFAIK (i didn't write a test), fchroot() outside of the chroot
is already disallowed by the
m...@netbsd.org (Emmanuel Dreyfus) writes:
Alan Barrett a...@netbsd.org wrote:
The fexecve function could be implemented entirely in libc,
via execve(2) on a file name of the form /proc/self/fd/N.
Any security concerns around fexecve() also apply to exec of
/proc/self/fd/N.
I gave a try
The fexecve function could be implemented entirely in libc,
via execve(2) on a file name of the form /proc/self/fd/N.
Any security concerns around fexecve() also apply to exec of
/proc/self/fd/N.
I gave a try to this approach. There is an unexpected issue:
The descriptor is probably already
On Tue, 4 Dec 2012 08:49:17 + (UTC)
mlel...@serpens.de (Michael van Elst) wrote:
The descriptor is probably already closed on exec before the syscall
tries to use it.
Nope. That happens later. I was looking through this code yesterday as
the topic interests me. The namei lookup happens
On Tue, Dec 04, 2012 at 01:58:13PM +, Julian Yon wrote:
The descriptor is probably already closed on exec before the syscall
tries to use it.
Nope. That happens later. I was looking through this code yesterday as
the topic interests me. The namei lookup happens pretty early on. I
Date:Tue, 4 Dec 2012 15:44:47 +0300
From:Alan Barrett a...@cequrux.com
Message-ID: 20121204124447.gf8...@apb-laptoy.apb.alt.za
| The fexecve function could be implemented entirely in libc,
| via execve(2) on a file name of the form /proc/self/fd/N.
| Any
On Tue, 4 Dec 2012 15:30:36 +
David Holland dholland-t...@netbsd.org wrote:
On Tue, Dec 04, 2012 at 01:58:13PM +, Julian Yon wrote:
The descriptor is probably already closed on exec before the
syscall tries to use it.
Nope. That happens later. I was looking through this
On Tue, Dec 04, 2012 at 11:42:04PM +0700, Robert Elz wrote:
Even chroot isn't a problem, unless you're tempted to view it as some
kind of security mechanism. It really isn't - it is just namespace
modification. Sure, by modifying the filesystem namespace a bunch
of simple security
Alan Barrett a...@netbsd.org wrote:
The fexecve function could be implemented entirely in libc,
via execve(2) on a file name of the form /proc/self/fd/N.
Any security concerns around fexecve() also apply to exec of
/proc/self/fd/N.
I gave a try to this approach. There is an unexpected
On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
If necessary, the open(2) syscall could be versioned so that
O_RDONLY is no longer defined as zero.
This seems possibly worth doing to avoid all the annoyance with
FREAD/FWRITE vs. O_RDONLY/O_WRONLY, but I really don't see how it's
On Wed, Nov 28, 2012 at 03:12:36PM +, David Holland wrote:
On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
If necessary, the open(2) syscall could be versioned so that
O_RDONLY is no longer defined as zero.
This seems possibly worth doing to avoid all the annoyance
On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
If necessary, the open(2) syscall could be versioned so that
O_RDONLY is no longer defined as zero.
Actually we could redefine (say)
O_RDONLY0x1
O_WRONLY0x2
O_RDWR (O_RDONLY
On Mon, Nov 26, 2012 at 09:01:10AM +, David Laight wrote:
O_SEARCH0x4
O_EXEC 0x8
The standard notes that O_EXEC and O_SEARCH are never used together
and therefore may be set to the same binary value.
--
Emmanuel Dreyfus
m...@netbsd.org
27 matches
Mail list logo
