On 2016-07-31 13:45, Eric W. Biederman wrote:
> Mateusz Guzik writes:
>
> > On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
> >> So what I am requesting is very simple. That the checks in
> >> prctl_set_mm_exe_file be tightened up to more closely approach
On 2016-07-31 13:45, Eric W. Biederman wrote:
> Mateusz Guzik writes:
>
> > On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
> >> So what I am requesting is very simple. That the checks in
> >> prctl_set_mm_exe_file be tightened up to more closely approach what
> >> execve
30.07.2016 19:31, Eric W. Biederman пишет:
Cyrill Gorcunov writes:
On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
...
Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
validate that the new file is a actually mmaped executable. We
30.07.2016 19:31, Eric W. Biederman пишет:
Cyrill Gorcunov writes:
On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
...
Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
validate that the new file is a actually mmaped executable. We would
definitely need
On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
...
>
> It is necessary to look at the ordinary situation. Without
> prctl_set_mm_exe /proc/[pid]/exe can be counted on as a record
> of which executable was last passed to execve.
True.
> Furthermore the state of a process can
On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
...
>
> It is necessary to look at the ordinary situation. Without
> prctl_set_mm_exe /proc/[pid]/exe can be counted on as a record
> of which executable was last passed to execve.
True.
> Furthermore the state of a process can
On Sun, Jul 31, 2016 at 3:43 PM, Cyrill Gorcunov wrote:
> On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
>> Cyrill Gorcunov writes:
>>
>> > On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
>> > ...
>> >> >>
>> >> >>
On Sun, Jul 31, 2016 at 3:43 PM, Cyrill Gorcunov wrote:
> On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
>> Cyrill Gorcunov writes:
>>
>> > On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
>> > ...
>> >> >>
>> >> >> Also there is a big fat bug in
On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
> Cyrill Gorcunov writes:
>
> > On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
> > ...
> >> >>
> >> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
> >> >> validate
On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
> Cyrill Gorcunov writes:
>
> > On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
> > ...
> >> >>
> >> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
> >> >> validate that the new file is a
Mateusz Guzik writes:
> On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
>> So what I am requesting is very simple. That the checks in
>> prctl_set_mm_exe_file be tightened up to more closely approach what
>> execve requires. Thus preserving the value of
Mateusz Guzik writes:
> On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
>> So what I am requesting is very simple. That the checks in
>> prctl_set_mm_exe_file be tightened up to more closely approach what
>> execve requires. Thus preserving the value of the /proc/[pid]/exe
On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
> So what I am requesting is very simple. That the checks in
> prctl_set_mm_exe_file be tightened up to more closely approach what
> execve requires. Thus preserving the value of the /proc/[pid]/exe for
> the applications that
On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
> So what I am requesting is very simple. That the checks in
> prctl_set_mm_exe_file be tightened up to more closely approach what
> execve requires. Thus preserving the value of the /proc/[pid]/exe for
> the applications that
Cyrill Gorcunov writes:
> On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
> ...
>> >>
>> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
>> >> validate that the new file is a actually mmaped executable. We would
>> >> definitely need
Cyrill Gorcunov writes:
> On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
> ...
>> >>
>> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
>> >> validate that the new file is a actually mmaped executable. We would
>> >> definitely need that to be fixed
25.07.2016 20:21, Eric W. Biederman пишет:
Stanislav Kinsburskiy writes:
Gentlemen,
Looks like there are no objections to this patch.
There has been objection.
The only justification for the change that has been put forward is
someone doing a restore lazily. I
25.07.2016 20:21, Eric W. Biederman пишет:
Stanislav Kinsburskiy writes:
Gentlemen,
Looks like there are no objections to this patch.
There has been objection.
The only justification for the change that has been put forward is
someone doing a restore lazily. I don't see a reason why you
On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
...
> >>
> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
> >> validate that the new file is a actually mmaped executable. We would
> >> definitely need that to be fixed before even considering removing the
>
On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
...
> >>
> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
> >> validate that the new file is a actually mmaped executable. We would
> >> definitely need that to be fixed before even considering removing the
>
Cyrill Gorcunov writes:
> On Mon, Jul 25, 2016 at 01:21:51PM -0500, Eric W. Biederman wrote:
>> Stanislav Kinsburskiy writes:
>>
>> > Gentlemen,
>> >
>> > Looks like there are no objections to this patch.
>>
>> There has been objection.
>>
>>
Cyrill Gorcunov writes:
> On Mon, Jul 25, 2016 at 01:21:51PM -0500, Eric W. Biederman wrote:
>> Stanislav Kinsburskiy writes:
>>
>> > Gentlemen,
>> >
>> > Looks like there are no objections to this patch.
>>
>> There has been objection.
>>
>> The only justification for the change that has
On Mon, Jul 25, 2016 at 01:21:51PM -0500, Eric W. Biederman wrote:
> Stanislav Kinsburskiy writes:
>
> > Gentlemen,
> >
> > Looks like there are no objections to this patch.
>
> There has been objection.
>
> The only justification for the change that has been put
On Mon, Jul 25, 2016 at 01:21:51PM -0500, Eric W. Biederman wrote:
> Stanislav Kinsburskiy writes:
>
> > Gentlemen,
> >
> > Looks like there are no objections to this patch.
>
> There has been objection.
>
> The only justification for the change that has been put forward is
> someone doing a
Stanislav Kinsburskiy writes:
> Gentlemen,
>
> Looks like there are no objections to this patch.
There has been objection.
The only justification for the change that has been put forward is
someone doing a restore lazily. I don't see a reason why you can't call
Stanislav Kinsburskiy writes:
> Gentlemen,
>
> Looks like there are no objections to this patch.
There has been objection.
The only justification for the change that has been put forward is
someone doing a restore lazily. I don't see a reason why you can't call
prctl_set_mm_exe_file until you
18.07.2016 22:11, One Thousand Gnomes пишет:
1) Attach to process via ptrace (protected by CAP_SYS_PTRACE)
2) Unmap all the process file mappings, related to "exe" file.
3) Change exe link (protected by CAP_SYS_RESOURCE).
IOW, some other process already has an access to process internals (and
18.07.2016 22:11, One Thousand Gnomes пишет:
1) Attach to process via ptrace (protected by CAP_SYS_PTRACE)
2) Unmap all the process file mappings, related to "exe" file.
3) Change exe link (protected by CAP_SYS_RESOURCE).
IOW, some other process already has an access to process internals (and
> >> 1) Attach to process via ptrace (protected by CAP_SYS_PTRACE)
> >> 2) Unmap all the process file mappings, related to "exe" file.
> >> 3) Change exe link (protected by CAP_SYS_RESOURCE).
> >>
> >> IOW, some other process already has an access to process internals (and
> >> thus
> >> it's
> >> 1) Attach to process via ptrace (protected by CAP_SYS_PTRACE)
> >> 2) Unmap all the process file mappings, related to "exe" file.
> >> 3) Change exe link (protected by CAP_SYS_RESOURCE).
> >>
> >> IOW, some other process already has an access to process internals (and
> >> thus
> >> it's
12.07.2016 18:52, Eric W. Biederman пишет:
Cyrill Gorcunov writes:
On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:
This limitation came with the reason to remove "another
way for malicious code to obscure a compromised program and
masquerade as a
12.07.2016 18:52, Eric W. Biederman пишет:
Cyrill Gorcunov writes:
On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:
This limitation came with the reason to remove "another
way for malicious code to obscure a compromised program and
masquerade as a benign process" by
On 07/12, Stanislav Kinsburskiy wrote:
>
> Thank you for the explanation.
> So, if I understand you right, the patch should be left as it is.
> Is this statement correct?
Yes, yes, feel free to add my ack.
Oleg.
On 07/12, Stanislav Kinsburskiy wrote:
>
> Thank you for the explanation.
> So, if I understand you right, the patch should be left as it is.
> Is this statement correct?
Yes, yes, feel free to add my ack.
Oleg.
On Tue, Jul 12, 2016 at 08:29:33PM +0300, Cyrill Gorcunov wrote:
> On Tue, Jul 12, 2016 at 11:52:09AM -0500, Eric W. Biederman wrote:
> > >
> > > Persistent exe-link doesn't guarantee anything if you have rights to
> > > ptrace
> > > task and inject own code into (from security POV). So lets rip
On Tue, Jul 12, 2016 at 08:29:33PM +0300, Cyrill Gorcunov wrote:
> On Tue, Jul 12, 2016 at 11:52:09AM -0500, Eric W. Biederman wrote:
> > >
> > > Persistent exe-link doesn't guarantee anything if you have rights to
> > > ptrace
> > > task and inject own code into (from security POV). So lets rip
On Tue, Jul 12, 2016 at 11:52:09AM -0500, Eric W. Biederman wrote:
> >
> > Persistent exe-link doesn't guarantee anything if you have rights to ptrace
> > task and inject own code into (from security POV). So lets rip it out.
> >
> > Acked-by: Cyrill Gorcunov
>
> I believe
On Tue, Jul 12, 2016 at 11:52:09AM -0500, Eric W. Biederman wrote:
> >
> > Persistent exe-link doesn't guarantee anything if you have rights to ptrace
> > task and inject own code into (from security POV). So lets rip it out.
> >
> > Acked-by: Cyrill Gorcunov
>
> I believe the original concern
12.07.2016 18:42, Oleg Nesterov пишет:
On 07/12, Stanislav Kinsburskiy wrote:
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1696,16 +1696,6 @@ static int prctl_set_mm_exe_file(struct mm_struct *mm,
unsigned int fd)
fput(exe_file);
}
- /*
-* The symlink can be
12.07.2016 18:42, Oleg Nesterov пишет:
On 07/12, Stanislav Kinsburskiy wrote:
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1696,16 +1696,6 @@ static int prctl_set_mm_exe_file(struct mm_struct *mm,
unsigned int fd)
fput(exe_file);
}
- /*
-* The symlink can be
Cyrill Gorcunov writes:
> On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:
>> This limitation came with the reason to remove "another
>> way for malicious code to obscure a compromised program and
>> masquerade as a benign process" by allowing
Cyrill Gorcunov writes:
> On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:
>> This limitation came with the reason to remove "another
>> way for malicious code to obscure a compromised program and
>> masquerade as a benign process" by allowing "security-concious program can
On 07/12, Stanislav Kinsburskiy wrote:
>
> 12.07.2016 18:42, Oleg Nesterov пишет:
>> But I would like to ack it in any case. I never understood why do we
>> want/need this MMF_EXE_FILE_CHANGED check, I suggested to remove it
>> many times.
>>
>> And can't resist, please note the xchg() below.
On 07/12, Stanislav Kinsburskiy wrote:
>
> 12.07.2016 18:42, Oleg Nesterov пишет:
>> But I would like to ack it in any case. I never understood why do we
>> want/need this MMF_EXE_FILE_CHANGED check, I suggested to remove it
>> many times.
>>
>> And can't resist, please note the xchg() below.
On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:
> This limitation came with the reason to remove "another
> way for malicious code to obscure a compromised program and
> masquerade as a benign process" by allowing "security-concious program can use
> this prctl once during
On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:
> This limitation came with the reason to remove "another
> way for malicious code to obscure a compromised program and
> masquerade as a benign process" by allowing "security-concious program can use
> this prctl once during
On 07/12, Stanislav Kinsburskiy wrote:
>
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -1696,16 +1696,6 @@ static int prctl_set_mm_exe_file(struct mm_struct *mm,
> unsigned int fd)
> fput(exe_file);
> }
>
> - /*
> - * The symlink can be changed only once, just to
On 07/12, Stanislav Kinsburskiy wrote:
>
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -1696,16 +1696,6 @@ static int prctl_set_mm_exe_file(struct mm_struct *mm,
> unsigned int fd)
> fput(exe_file);
> }
>
> - /*
> - * The symlink can be changed only once, just to
This limitation came with the reason to remove "another
way for malicious code to obscure a compromised program and
masquerade as a benign process" by allowing "security-concious program can use
this prctl once during its early initialization to ensure the prctl cannot
later be abused for this
This limitation came with the reason to remove "another
way for malicious code to obscure a compromised program and
masquerade as a benign process" by allowing "security-concious program can use
this prctl once during its early initialization to ensure the prctl cannot
later be abused for this
This limitation came with the reason to remove "another
way for malicious code to obscure a compromised program and
masquerade as a benign process" by allowing "security-concious program can use
this prctl once during its early initialization to ensure the prctl cannot
later be abused for this
This limitation came with the reason to remove "another
way for malicious code to obscure a compromised program and
masquerade as a benign process" by allowing "security-concious program can use
this prctl once during its early initialization to ensure the prctl cannot
later be abused for this
52 matches
Mail list logo