On 10/11/2014 12:06 AM, Steven J. Long wrote:
> On Sun, Oct 05, 2014, Zac Medico wrote:
>> On 10/02/2014 07:32 PM, Steven J. Long wrote:
>>> On Tue, Sep 30, 2014, Zac Medico wrote:
> On Mon, Sep 29, 2014, Zac Medico wrote:
>> We control the shell code that launches the requested command, so
On Sun, Oct 05, 2014, Zac Medico wrote:
> On 10/02/2014 07:32 PM, Steven J. Long wrote:
> > On Tue, Sep 30, 2014, Zac Medico wrote:
> >>> On Mon, Sep 29, 2014, Zac Medico wrote:
> We control the shell code that launches the requested command, so we can
> save the environment after the req
Steven J. Long wrote:
> > It's a lot more secure to have a single well-defined privileged trust
> > anchor (the privileged process) with a well-defined protocol, than to
> > have built-in privilege escalation which allows arbitrary actions.
>
> You appear to have missed the point of what it does.
On Fri, Oct 03, 2014 at 05:01:20AM +0200, Peter Stuge wrote:
> Steven J. Long wrote:
> > On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote:
> > > The IPC implementation that I've suggested does not involve an SUID
> > > helper, so it is much more secure. Security would rely on the permissi
On 09/28/2014 09:23 PM, Steven J. Long wrote:
> On Wed, Sep 24, 2014 at 09:51:31PM -0700, Zac Medico wrote:
>> On 07/09/2014 07:17 AM, Michał Górny wrote:
> c) 'esudo' helper [3]. This is a more generic form of (2), with
> support for other potential privilege changes.
> ..
>>> I don't
On Wed, Sep 24, 2014 at 09:51:31PM -0700, Zac Medico wrote:
> On 07/09/2014 07:17 AM, Michał Górny wrote:
> >>> c) 'esudo' helper [3]. This is a more generic form of (2), with
> >>> support for other potential privilege changes.
> >>
..
> > I don't think we'd use the reference 'sudo' impl. Rather s
