Default permissions on supervise/ok

Default permissions on supervise/ok

[eam]

I'd like to allow any user to access supervise/ok, in order to run
`sv stat`, but not to access supervise/control. My understanding is that
this is safe, as supervise/ok is a read-only interface. Is this accurate,
and is this a reasonable idea? Anything I should be warned about? Am I
overlooking anything important?

chmod 755 supervise
chmod 666 supervise/ok

Re: Default permissions on supervise/ok

[Charlie Brady]

On Mon, 20 May 2013, eam@frap.net wrote:

> I'd like to allow any user to access supervise/ok, in order to run
> `sv stat`, but not to access supervise/control. My understanding is that
> this is safe, as supervise/ok is a read-only interface. Is this accurate,
> and is this a reasonable idea? Anything I should be warned about? Am I
> overlooking anything important?
> 
> chmod 755 supervise
> chmod 666 supervise/ok

Why wouldn't you use 644 for supervise/ok? Remember that you have no 
guarantee that Joe User will use 'sv' to access the file.

Re: Default permissions on supervise/ok

[eam]

On Mon, May 20, 2013 at 08:47:37PM -0400, Charlie Brady wrote:
> 
> On Mon, 20 May 2013, eam@frap.net wrote:
> 
> > I'd like to allow any user to access supervise/ok, in order to run
> > `sv stat`, but not to access supervise/control. My understanding is that
> > this is safe, as supervise/ok is a read-only interface. Is this accurate,
> > and is this a reasonable idea? Anything I should be warned about? Am I
> > overlooking anything important?
> > 
> > chmod 755 supervise
> > chmod 666 supervise/ok
> 
> Why wouldn't you use 644 for supervise/ok? Remember that you have no 
> guarantee that Joe User will use 'sv' to access the file.

sv refuses to run if it can't open the fifo as writable. My intent is to
allow any user to inspect the process state, but not influence it.

My understanding is that runsv will never read from the fifo, and will
only use opening it as a test to verify the process exists the other end.
This doesn't seem exploitable as it's a read-only channel. At least, as
far as I can tell.

supervise/status already has 644 perms, which is fine because `sv` opens
it readonly, but the default permission on the parent supervise/ directory
are 700 which prohibits access.

Control of runsv is performed over supervise/control, which I would not
make world or group writable, of course.

Re: Default permissions on supervise/ok

[Laurent Bercot]

> My understanding is that runsv will never read from the fifo, and will
> only use opening it as a test to verify the process exists the other end.
> This doesn't seem exploitable as it's a read-only channel. At least, as
> far as I can tell.

 Here's an exploit:

 If runsv is down, "sv status" will normally return a "runsv not running"
message. But if some user has supervise/ok open for reading, "sv status"
will mistakenly think runsv is running, because it assumes runsv is the
only process able to keep supervise/ok open for reading. So, a user can
deny a service recovery routine from running.

 Don't meddle with supervise/ permissions. If you want to trust a group
of users with service checking/control abilities, make the sv binary
setgid.
 Unfortunately, runit does not separate service checking and service
control abilities at the executable level, so I'm afraid you cannot
achieve what you want here.

 Shameless plug: you could switch s6, which gives you s6-svok and
s6-svstat executables for service checking, separate from the s6-svc
executable for service control. You can make s6-svok and s6-svstat
setgid at your convenience, without endangering the reliability of the
service.

-- 
 Laurent

Re: Default permissions on supervise/ok

[eam]

On Tue, May 21, 2013 at 11:58:14AM +0200, Laurent Bercot wrote:
> > My understanding is that runsv will never read from the fifo, and will
> > only use opening it as a test to verify the process exists the other end.
> > This doesn't seem exploitable as it's a read-only channel. At least, as
> > far as I can tell.
> 
>  Here's an exploit:
> 
>  If runsv is down, "sv status" will normally return a "runsv not running"
> message. But if some user has supervise/ok open for reading, "sv status"
> will mistakenly think runsv is running, because it assumes runsv is the
> only process able to keep supervise/ok open for reading. So, a user can
> deny a service recovery routine from running.

Hm, interesting. Though 622 permissions would correct this, right?
Writable, but not readable?

Any concerns about making the directory readable and executable?

Re: Default permissions on supervise/ok

[Laurent Bercot]

> Hm, interesting. Though 622 permissions would correct this, right?
> Writable, but not readable?

 I think it would work, yes, but I haven't thought too much about it.
Don't quote me on that ^^


> Any concerns about making the directory readable and executable?

 That shouldn't cause any problems.

-- 
 Laurent