David Madore wrote:
>I intend to add a couple of capabilities which are normally available
>to all user processes, including capability to exec(), [...]
Once you have a mechanism that lets you prevent the untrusted program
from exec-ing a setuid/setgid program (such as your bounding set idea),
I
On Tue, 9 Aug 2005, Chris Wright wrote:
> * Bodo Eggert ([EMAIL PROTECTED]) wrote:
> > 1) I wouldn't want an exploited service to gain any privileges, even by
> >chaining userspace exploits (e.g. exec sendmail < exploitstring). For
> >most services, I'd like CAP_EXEC being unset (but it
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
> 1) I wouldn't want an exploited service to gain any privileges, even by
>chaining userspace exploits (e.g. exec sendmail < exploitstring). For
>most services, I'd like CAP_EXEC being unset (but it doesn't exist).
Don't let it exec things it
On Tue, Aug 09, 2005 at 11:36:00PM +0200, Bodo Eggert wrote:
> 1) I wouldn't want an exploited service to gain any privileges, even by
>chaining userspace exploits (e.g. exec sendmail < exploitstring). For
>most services, I'd like CAP_EXEC being unset (but it doesn't exist).
I intend to
On Tue, 9 Aug 2005, Chris Wright wrote:
> * Bodo Eggert ([EMAIL PROTECTED]) wrote:
> > Chris Wright <[EMAIL PROTECTED]> wrote:
> > > * David Madore ([EMAIL PROTECTED]) wrote:
> > >> * Second, a much more extensive change, the patch introduces a third
> > >> set of capabilities for every process,
On Tue, Aug 09, 2005 at 01:52:06PM -0700, Chris Wright wrote:
> * Bodo Eggert ([EMAIL PROTECTED]) wrote:
> > How are you going to tell processes that may exec suid (or set-capability-)
> > programs from those that aren't supposed to gain certain capabilities?
>
> typically you'd expect exec suid
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
> Chris Wright <[EMAIL PROTECTED]> wrote:
> > * David Madore ([EMAIL PROTECTED]) wrote:
>
> >> * Second, a much more extensive change, the patch introduces a third
> >> set of capabilities for every process, the "bounding" set. Normally
> >
> > this is
On Tue, Aug 09, 2005 at 04:28:31PM -0400, [EMAIL PROTECTED] wrote:
> On Tue, 09 Aug 2005 07:26:21 +0200, David Madore said:
> > * Second, a much more extensive change, the patch introduces a third
> > set of capabilities for every process, the "bounding" set. Normally
> > the bounding set has
On Tue, Aug 09, 2005 at 05:37:56AM +, Chris Wright wrote:
> * David Madore ([EMAIL PROTECTED]) wrote:
> > * Second, a much more extensive change, the patch introduces a third
> > set of capabilities for every process, the "bounding" set. Normally
>
> this is not a good idea. don't add more
On Tue, 09 Aug 2005 07:26:21 +0200, David Madore said:
> * Second, a much more extensive change, the patch introduces a third
> set of capabilities for every process, the "bounding" set. Normally
> the bounding set has every capability in it
How is this different in semantics from the existing
Chris Wright <[EMAIL PROTECTED]> wrote:
> * David Madore ([EMAIL PROTECTED]) wrote:
>> * Second, a much more extensive change, the patch introduces a third
>> set of capabilities for every process, the "bounding" set. Normally
>
> this is not a good idea. don't add more sets. if you really
Chris Wright [EMAIL PROTECTED] wrote:
* David Madore ([EMAIL PROTECTED]) wrote:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding set. Normally
this is not a good idea. don't add more sets. if you really want to
work
On Tue, 09 Aug 2005 07:26:21 +0200, David Madore said:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding set. Normally
the bounding set has every capability in it
How is this different in semantics from the existing
On Tue, Aug 09, 2005 at 05:37:56AM +, Chris Wright wrote:
* David Madore ([EMAIL PROTECTED]) wrote:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding set. Normally
this is not a good idea. don't add more sets.
On Tue, Aug 09, 2005 at 04:28:31PM -0400, [EMAIL PROTECTED] wrote:
On Tue, 09 Aug 2005 07:26:21 +0200, David Madore said:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding set. Normally
the bounding set has every
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
Chris Wright [EMAIL PROTECTED] wrote:
* David Madore ([EMAIL PROTECTED]) wrote:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding set. Normally
this is not a good idea.
On Tue, Aug 09, 2005 at 01:52:06PM -0700, Chris Wright wrote:
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
How are you going to tell processes that may exec suid (or set-capability-)
programs from those that aren't supposed to gain certain capabilities?
typically you'd expect exec suid will
On Tue, 9 Aug 2005, Chris Wright wrote:
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
Chris Wright [EMAIL PROTECTED] wrote:
* David Madore ([EMAIL PROTECTED]) wrote:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding
On Tue, Aug 09, 2005 at 11:36:00PM +0200, Bodo Eggert wrote:
1) I wouldn't want an exploited service to gain any privileges, even by
chaining userspace exploits (e.g. exec sendmail exploitstring). For
most services, I'd like CAP_EXEC being unset (but it doesn't exist).
I intend to add
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
1) I wouldn't want an exploited service to gain any privileges, even by
chaining userspace exploits (e.g. exec sendmail exploitstring). For
most services, I'd like CAP_EXEC being unset (but it doesn't exist).
Don't let it exec things it
On Tue, 9 Aug 2005, Chris Wright wrote:
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
1) I wouldn't want an exploited service to gain any privileges, even by
chaining userspace exploits (e.g. exec sendmail exploitstring). For
most services, I'd like CAP_EXEC being unset (but it doesn't
David Madore wrote:
I intend to add a couple of capabilities which are normally available
to all user processes, including capability to exec(), [...]
Once you have a mechanism that lets you prevent the untrusted program
from exec-ing a setuid/setgid program (such as your bounding set idea),
I
* David Madore ([EMAIL PROTECTED]) wrote:
> * Second, a much more extensive change, the patch introduces a third
> set of capabilities for every process, the "bounding" set. Normally
this is not a good idea. don't add more sets. if you really want to
work on this i'll give you all the patches
Well, I wasn't sleepy tonight, so I produced the following patch for
Linux capabilities, which attempts to make them useful. It is
supposed to do the following (which may or may not conform with the
POSIX semantics, I don't think it matters much):
* First, and most importantly, capabilities are
Well, I wasn't sleepy tonight, so I produced the following patch for
Linux capabilities, which attempts to make them useful. It is
supposed to do the following (which may or may not conform with the
POSIX semantics, I don't think it matters much):
* First, and most importantly, capabilities are
* David Madore ([EMAIL PROTECTED]) wrote:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding set. Normally
this is not a good idea. don't add more sets. if you really want to
work on this i'll give you all the patches that
26 matches
Mail list logo
