On Wed, Jul 22, 2015 at 1:25 PM, Lennart Poettering
wrote:
> On Mon, 20.07.15 13:20, Florian Weimer (fwei...@redhat.com) wrote:
>
>> (d) Change the Go program to optionally drop capabilities and switch the
>> user. Do not use fscaps, and keep running it as full root initially.
>> This is the clea
On Wed, Jul 22, 2015 at 1:22 PM, Lennart Poettering
wrote:
> What's worse is that in kernels before 2.6.24 passing caps across
> exec() actually worked fine. Kernel broke API heavily in this regard
> by introducing fcaps and altering the caps inheritance logic then.
Are you sure? I don't recall
On Mon, 20.07.15 13:20, Florian Weimer (fwei...@redhat.com) wrote:
> (d) Change the Go program to optionally drop capabilities and switch the
> user. Do not use fscaps, and keep running it as full root initially.
> This is the cleanest approach and what other services use, but I don't
> think Go
On Sat, 18.07.15 10:42, Florian Weimer (fwei...@redhat.com) wrote:
> Let's assume I want to start a service as an ordinary user, but allow to
> bind it to a privileged port. The program implementing the service does
> not manipulate capabilities in any way.
>
> I came up with with this system un
On Jul 21, 2015 4:18 AM, "Florian Weimer" wrote:
>
> On 07/20/2015 07:30 PM, Andrew Lutomirski wrote:
>
> >> (b) Make a copy of the file, put it in a directory which only the
> >> service user can read (or ship it with 750 permissions and the service
> >> group controlling it), and set fscaps. Th
On 07/20/2015 07:30 PM, Andrew Lutomirski wrote:
>> (b) Make a copy of the file, put it in a directory which only the
>> service user can read (or ship it with 750 permissions and the service
>> group controlling it), and set fscaps. The downside is the large binary
>> size (it has to be a copy,
On 07/21/2015 06:22 AM, Steve Grubb wrote:
> Sure, there are cases where you know that. But let's take 'ping' as an
> example
> of what I'm talking about. It should never have children. If it does, its
> been
> exploited.
You can't know that. ping performs name resolution, and it's perfectly
On Tuesday, July 21, 2015 01:02:25 AM Reindl Harald wrote:
> Am 20.07.2015 um 23:34 schrieb Steve Grubb:
> > On Monday, July 20, 2015 12:45:28 PM Andrew Lutomirski wrote:
> >> On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb wrote:
> >>> The real problem with capabilities is there is no way to say, I
Am 20.07.2015 um 23:34 schrieb Steve Grubb:
On Monday, July 20, 2015 12:45:28 PM Andrew Lutomirski wrote:
On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb wrote:
The real problem with capabilities is there is no way to say, I trust this
child process with this capability, but don't let it get in
On Mon, Jul 20, 2015 at 2:34 PM, Steve Grubb wrote:
> On Monday, July 20, 2015 12:45:28 PM Andrew Lutomirski wrote:
>> On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb wrote:
>> > On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote:
>> >> On Jul 20, 2015 11:05 AM, "Florian Weimer" wrote:
>
On Monday, July 20, 2015 12:45:28 PM Andrew Lutomirski wrote:
> On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb wrote:
> > On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote:
> >> On Jul 20, 2015 11:05 AM, "Florian Weimer" wrote:
> >> > On 07/20/2015 05:59 PM, Steve Grubb wrote:
> >> > >
On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb wrote:
> On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote:
>> On Jul 20, 2015 11:05 AM, "Florian Weimer" wrote:
>> > On 07/20/2015 05:59 PM, Steve Grubb wrote:
>> > > Today, any application that wants to manipulate capabilities needs to be
On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote:
> On Jul 20, 2015 11:05 AM, "Florian Weimer" wrote:
> > On 07/20/2015 05:59 PM, Steve Grubb wrote:
> > > Today, any application that wants to manipulate capabilities needs to be
> > > capability aware.
> >
> > The application does not
On Jul 20, 2015 11:05 AM, "Florian Weimer" wrote:
>
> On 07/20/2015 05:59 PM, Steve Grubb wrote:
>
> > Today, any application that wants to manipulate capabilities needs to be
> > capability aware.
>
> The application does not want to manipulate capabilities. I do not want
> to run it as full roo
On 07/20/2015 05:59 PM, Steve Grubb wrote:
> Today, any application that wants to manipulate capabilities needs to be
> capability aware.
The application does not want to manipulate capabilities. I do not want
to run it as full root. I don't want to add additional SUID/fscaps to
the file syste
On Jul 20, 2015 4:20 AM, "Florian Weimer" wrote:
>
> On 07/18/2015 03:53 PM, Andrew Lutomirski wrote:
>
> > Nothing. Inheritable capabilities are nearly useless.
>
> Wow.
>
> The program that sparked this thread is a Go program. So basically, we
> have these options if we do not want to run with
On Monday, July 20, 2015 04:27:35 PM Florian Weimer wrote:
> >> The algorithm documented in capabilities(7) suggests that retaining
> >> effective capabilities across an execve system call absolutely requires
> >> file capabilities (the inheritable part).
> >
> >
> >
> > No. You can start off as r
On 07/20/2015 04:21 PM, Steve Grubb wrote:
> On Saturday, July 18, 2015 10:42:43 AM Florian Weimer wrote:
>> Let's assume I want to start a service as an ordinary user, but allow to
>> bind it to a privileged port. The program implementing the service does
>> not manipulate capabilities in any way
On Saturday, July 18, 2015 10:42:43 AM Florian Weimer wrote:
> Let's assume I want to start a service as an ordinary user, but allow to
> bind it to a privileged port. The program implementing the service does
> not manipulate capabilities in any way.
>
> I came up with with this system unit for
On 07/20/2015 02:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Jul 18, 2015 at 10:42:43AM +0200, Florian Weimer wrote:
>> Let's assume I want to start a service as an ordinary user, but allow to
>> bind it to a privileged port. The program implementing the service does
>> not manipulate capa
On Sat, Jul 18, 2015 at 10:42:43AM +0200, Florian Weimer wrote:
> Let's assume I want to start a service as an ordinary user, but allow to
> bind it to a privileged port. The program implementing the service does
> not manipulate capabilities in any way.
socket activation would be a much simpler a
On 07/18/2015 03:53 PM, Andrew Lutomirski wrote:
> Nothing. Inheritable capabilities are nearly useless.
Wow.
The program that sparked this thread is a Go program. So basically, we
have these options if we do not want to run with full capabilities:
(a) Run with UID=0 with restricted capabilit
On Jul 18, 2015 1:42 AM, "Florian Weimer" wrote:
>
> Let's assume I want to start a service as an ordinary user, but allow to
> bind it to a privileged port. The program implementing the service does
> not manipulate capabilities in any way.
>
> I came up with with this system unit for testing pu
Let's assume I want to start a service as an ordinary user, but allow to
bind it to a privileged port. The program implementing the service does
not manipulate capabilities in any way.
I came up with with this system unit for testing purposes:
[Unit]
Description=Test unit
[Service]
Type=oneshot
24 matches
Mail list logo
