Hello,
I've posted my idea to improve web-application security a few times
however, it could not interest folks unfortunatelly. :(
So, I would like to offer another approach for the purpose.
The attached patch is a proof of the concept of newer idea.
Any comments are welcome, and please feel free.
Explain first why using FASTCGI and suexec wouldn't be a better option?
It concerns me that in your plans, even though you are changing the
security context of a single thread within an existing process, that
that thread may still has access to all the process memory and so
could read or modify me
Graham Dumpleton wrote:
> Explain first why using FASTCGI and suexec wouldn't be a better option?
Thease are limited to cgi applications, so we cannot apply such kind
of restriction on the built-in script languages and references on
static documents (like *.html).
# For example, when we want to a
2009/4/8 KaiGai Kohei :
> Graham Dumpleton wrote:
>> Explain first why using FASTCGI and suexec wouldn't be a better option?
>
> Thease are limited to cgi applications, so we cannot apply such kind
> of restriction on the built-in script languages and references on
> static documents (like *.html).
Graham Dumpleton wrote:
> 2009/4/8 KaiGai Kohei :
>> Graham Dumpleton wrote:
>>> Explain first why using FASTCGI and suexec wouldn't be a better option?
>> Thease are limited to cgi applications, so we cannot apply such kind
>> of restriction on the built-in script languages and references on
>> st
2009/4/8 KaiGai Kohei :
> Graham Dumpleton wrote:
>> 2009/4/8 KaiGai Kohei :
>>> Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better option?
>>> Thease are limited to cgi applications, so we cannot apply such kind
>>> of restriction on the built-in script la
On 8 Apr 2009, at 03:27, Graham Dumpleton wrote:
[following up to Graham because two posts by him are all I have
in this thread]
2009/4/8 KaiGai Kohei :
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better
option?
Thease are limited to cgi applications,
KaiGai Kohei wrote:
> Graham Dumpleton wrote:
>> 2009/4/8 KaiGai Kohei :
>>> Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better option?
>>> Thease are limited to cgi applications, so we cannot apply such kind
>>> of restriction on the built-in script langua
2009/4/8 KaiGai Kohei :
> KaiGai Kohei wrote:
>> Graham Dumpleton wrote:
>>> 2009/4/8 KaiGai Kohei :
Graham Dumpleton wrote:
> Explain first why using FASTCGI and suexec wouldn't be a better option?
Thease are limited to cgi applications, so we cannot apply such kind
of restricti
Nick Kew wrote:
>
> On 8 Apr 2009, at 03:27, Graham Dumpleton wrote:
>
> [following up to Graham because two posts by him are all I have
> in this thread]
>
>> 2009/4/8 KaiGai Kohei :
>>> Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better option?
>>>
>>>
Graham Dumpleton wrote:
> 2009/4/8 KaiGai Kohei :
>> KaiGai Kohei wrote:
>>> Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei :
> Graham Dumpleton wrote:
>> Explain first why using FASTCGI and suexec wouldn't be a better option?
> Thease are limited to cgi applications, so we cannot a
On Wed, Apr 08, 2009 at 10:38:52AM +0900, KaiGai Kohei wrote:
> I've posted my idea to improve web-application security a few times
> however, it could not interest folks unfortunatelly. :(
> So, I would like to offer another approach for the purpose.
> The attached patch is a proof of the concept
2009/4/8 KaiGai Kohei :
> Graham Dumpleton wrote:
>> 2009/4/8 KaiGai Kohei :
>>> KaiGai Kohei wrote:
Graham Dumpleton wrote:
> 2009/4/8 KaiGai Kohei :
>> Graham Dumpleton wrote:
>>> Explain first why using FASTCGI and suexec wouldn't be a better option?
>> Thease are limited to
On 8 Apr 2009, at 08:32, Joe Orton wrote:
So I'm not sure that it's worthwhile. Having said that, it seems a
lot
more worthwhile than the mod_privileges approach in the trunk, which
seems to claim it is secure so long as you don't execute untrusted
code,
so I'm not sure what threat model
Joe Orton wrote:
> On Wed, Apr 08, 2009 at 10:38:52AM +0900, KaiGai Kohei wrote:
>> I've posted my idea to improve web-application security a few times
>> however, it could not interest folks unfortunatelly. :(
>> So, I would like to offer another approach for the purpose.
>> The attached patch is
On Wed, Apr 08, 2009 at 09:09:14AM +0100, Nick Kew wrote:
>
> On 8 Apr 2009, at 08:32, Joe Orton wrote:
>
>> So I'm not sure that it's worthwhile. Having said that, it seems a
>> lot more worthwhile than the mod_privileges approach in the trunk,
>> which seems to claim it is secure so long as yo
Graham Dumpleton wrote:
> 2009/4/8 KaiGai Kohei :
>> Graham Dumpleton wrote:
>>> 2009/4/8 KaiGai Kohei :
KaiGai Kohei wrote:
> Graham Dumpleton wrote:
>> 2009/4/8 KaiGai Kohei :
>>> Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better opt
Joe Orton wrote:
> On Wed, Apr 08, 2009 at 09:09:14AM +0100, Nick Kew wrote:
>> On 8 Apr 2009, at 08:32, Joe Orton wrote:
>>
>>> So I'm not sure that it's worthwhile. Having said that, it seems a
>>> lot more worthwhile than the mod_privileges approach in the trunk,
>>> which seems to claim it i
KaiGai Kohei wrote:
> However, SElinux does not allow to revert its privilege (security context)
> unconditionally, even if it is dynamically changed.
> If we want to revert it, the security policy has to allow B->A in addition
> to A->B, but it is generally nonsense.
> It is also the reason why we
William A. Rowe, Jr. wrote:
> KaiGai Kohei wrote:
>> However, SElinux does not allow to revert its privilege (security context)
>> unconditionally, even if it is dynamically changed.
>> If we want to revert it, the security policy has to allow B->A in addition
>> to A->B, but it is generally nonsen
2009/4/9 KaiGai Kohei :
> William A. Rowe, Jr. wrote:
>> KaiGai Kohei wrote:
>>> However, SElinux does not allow to revert its privilege (security context)
>>> unconditionally, even if it is dynamically changed.
>>> If we want to revert it, the security policy has to allow B->A in addition
>>> to A
Graham Dumpleton wrote:
> 2009/4/9 KaiGai Kohei :
>> William A. Rowe, Jr. wrote:
>>> KaiGai Kohei wrote:
However, SElinux does not allow to revert its privilege (security context)
unconditionally, even if it is dynamically changed.
If we want to revert it, the security policy has to
2009/4/9 KaiGai Kohei :
> Graham Dumpleton wrote:
>> 2009/4/9 KaiGai Kohei :
>>> William A. Rowe, Jr. wrote:
KaiGai Kohei wrote:
> However, SElinux does not allow to revert its privilege (security context)
> unconditionally, even if it is dynamically changed.
> If we want to revert
>> The reason why I would like to set privilege prior to the invocation
>> of contents handler is to apply consistent access controls independent
>> from what kind of script languages are used.
>
> I understand that, but you seem to be focused on the idea of using
> threads within a process and th
2009/4/9 KaiGai Kohei :
>>> The reason why I would like to set privilege prior to the invocation
>>> of contents handler is to apply consistent access controls independent
>>> from what kind of script languages are used.
>>
>> I understand that, but you seem to be focused on the idea of using
>> th
Graham Dumpleton wrote:
> 2009/4/9 KaiGai Kohei :
The reason why I would like to set privilege prior to the invocation
of contents handler is to apply consistent access controls independent
from what kind of script languages are used.
>>> I understand that, but you seem to be focused
2009/4/9 KaiGai Kohei :
> Graham Dumpleton wrote:
>> 2009/4/9 KaiGai Kohei :
> The reason why I would like to set privilege prior to the invocation
> of contents handler is to apply consistent access controls independent
> from what kind of script languages are used.
I understand t
On Thursday 09 April 2009, Graham Dumpleton wrote:
> Only you would know that. But then, I could be pointing you at the
> wrong MPM. There is from memory another by another name developed
> outside of ASF which intends to do the same think. The way it is
> implemented is probably going to be differ
Stefan Fritsch wrote:
> On Thursday 09 April 2009, Graham Dumpleton wrote:
>> Only you would know that. But then, I could be pointing you at the
>> wrong MPM. There is from memory another by another name developed
>> outside of ASF which intends to do the same think. The way it is
>> implemented is
W dniu 2009-04-09, o godz. 18:19, Stefan Fritsch
napisał(a):
On Thursday 09 April 2009, Graham Dumpleton wrote:
Only you would know that. But then, I could be pointing you at the
wrong MPM. There is from memory another by another name developed
outside of ASF which intends to do the same t
KaiGai Kohei wrote:
> Stefan Fritsch wrote:
>> On Thursday 09 April 2009, Graham Dumpleton wrote:
>>> Only you would know that. But then, I could be pointing you at the
>>> wrong MPM. There is from memory another by another name developed
>>> outside of ASF which intends to do the same think. The w
31 matches
Mail list logo
