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 d
* 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 shoul
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 a
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, t
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 w
* 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 no
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 ever
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 s
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 want
* 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 th
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 c
13 matches
Mail list logo