sndiod on by default (does it need to be ? )

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

sndiod on by default (does it need to be ? )

Tom Smyth
Hello,

I was wondering should sndiod (default) startup be determined based on
whether or not
it the install is a typical headless install (off) or  an install for
a user machine with  running X

is there a reason why one would need to run this daemon by default?

my thinking is by having the service off by default would reduce the
default attack surface of the OS ?

perhaps the installer could use the answer to the question do you
intend to run X   to determine whether or not to enable the sndiod
daemon ?

I hope this helps

--
Kindest regards,
Tom Smyth.

Reply | Threaded
Open this post in threaded view
|

Re: sndiod on by default (does it need to be ? )

Sebastian Benoit
Tom Smyth([hidden email]) on 2021.02.21 04:08:48 +0000:
> Hello,
>
> I was wondering should sndiod (default) startup be determined based on
> whether or not
> it the install is a typical headless install (off) or  an install for
> a user machine with  running X
>
> is there a reason why one would need to run this daemon by default?

Because users want to listen to audio.

> my thinking is by having the service off by default would reduce the
> default attack surface of the OS ?

How big is that attack surface? And especially compared to X?
 
> perhaps the installer could use the answer to the question do you
> intend to run X   to determine whether or not to enable the sndiod
> daemon ?

The difference is that a running sndiod is not noticable to you. Running X
is - you dont have a console anymore on your screen.

Whereas a not running sndiod is noticable - no sound.

Next to security, we try to make it easy for people to use OpenBSD. Not
asking questions when not needed is just that.

/Benno

Reply | Threaded
Open this post in threaded view
|

Re: sndiod on by default (does it need to be ? )

Tom Smyth
Hi Sebastian
I get users want to listen to audio but if the only hardware is a buzzer
and the user is not running x what are the chances they are using audio on
the console only ?

I can keep running
rcctl disable sndiod
Post install

I thought linking audio support on by default to x would make sense as it
is likely such system is for users who may need audio

Just a thought
Thanks


On Sunday, 21 February 2021, Sebastian Benoit <[hidden email]> wrote:

> Tom Smyth([hidden email]) on 2021.02.21 04:08:48 +0000:
> > Hello,
> >
> > I was wondering should sndiod (default) startup be determined based on
> > whether or not
> > it the install is a typical headless install (off) or  an install for
> > a user machine with  running X
> >
> > is there a reason why one would need to run this daemon by default?
>
> Because users want to listen to audio.
>
> > my thinking is by having the service off by default would reduce the
> > default attack surface of the OS ?
>
> How big is that attack surface? And especially compared to X?
>
> > perhaps the installer could use the answer to the question do you
> > intend to run X   to determine whether or not to enable the sndiod
> > daemon ?
>
> The difference is that a running sndiod is not noticable to you. Running X
> is - you dont have a console anymore on your screen.
>
> Whereas a not running sndiod is noticable - no sound.
>
> Next to security, we try to make it easy for people to use OpenBSD. Not
> asking questions when not needed is just that.
>
> /Benno
>


--
Kindest regards,
Tom Smyth.
Reply | Threaded
Open this post in threaded view
|

Re: sndiod on by default (does it need to be ? )

Abel Abraham Camarillo Ojeda-2
On Sun, Feb 21, 2021 at 8:39 AM Tom Smyth <[hidden email]>
wrote:

> Hi Sebastian
> I get users want to listen to audio but if the only hardware is a buzzer
> and the user is not running x what are the chances they are using audio on
> the console only ?
>
> I can keep running
> rcctl disable sndiod
> Post install
>
> I thought linking audio support on by default to x would make sense as it
> is likely such system is for users who may need audio
>
> Just a thought
> Thanks
>
>
> On Sunday, 21 February 2021, Sebastian Benoit <[hidden email]>
> wrote:
>
> > Tom Smyth([hidden email]) on 2021.02.21 04:08:48 +0000:
> > > Hello,
> > >
> > > I was wondering should sndiod (default) startup be determined based on
> > > whether or not
> > > it the install is a typical headless install (off) or  an install for
> > > a user machine with  running X
> > >
> > > is there a reason why one would need to run this daemon by default?
> >
> > Because users want to listen to audio.
> >
> > > my thinking is by having the service off by default would reduce the
> > > default attack surface of the OS ?
> >
> > How big is that attack surface? And especially compared to X?
> >
> > > perhaps the installer could use the answer to the question do you
> > > intend to run X   to determine whether or not to enable the sndiod
> > > daemon ?
> >
> > The difference is that a running sndiod is not noticable to you. Running
> X
> > is - you dont have a console anymore on your screen.
> >
> > Whereas a not running sndiod is noticable - no sound.
> >
> > Next to security, we try to make it easy for people to use OpenBSD. Not
> > asking questions when not needed is just that.
> >
> > /Benno
> >
>

I use audio with mpd + ncmpc, without X need. No thanks...


> --
> Kindest regards,
> Tom Smyth.
>
Reply | Threaded
Open this post in threaded view
|

Re: sndiod on by default (does it need to be ? )

Tom Smyth
In reply to this post by Tom Smyth
Hi folks,
thanks for everyone who replied on and off list,
I had not considered the console only user who uses audio also...
(I had not even considered this  so pardon my ignorance folks,
and thanks to Sebastian, Abel, and David for replying on and off list

I guess Ill just add rcctl disable sndiod to my deploy ment scripts
for my use cases :)

Thanks again to all who considered it

:)



On Sun, 21 Feb 2021 at 14:28, Tom Smyth <[hidden email]> wrote:

>
> Hi Sebastian
> I get users want to listen to audio but if the only hardware is a buzzer and the user is not running x what are the chances they are using audio on the console only ?
>
> I can keep running
> rcctl disable sndiod
> Post install
>
> I thought linking audio support on by default to x would make sense as it is likely such system is for users who may need audio
>
> Just a thought
> Thanks
>
>
> On Sunday, 21 February 2021, Sebastian Benoit <[hidden email]> wrote:
>>
>> Tom Smyth([hidden email]) on 2021.02.21 04:08:48 +0000:
>> > Hello,
>> >
>> > I was wondering should sndiod (default) startup be determined based on
>> > whether or not
>> > it the install is a typical headless install (off) or  an install for
>> > a user machine with  running X
>> >
>> > is there a reason why one would need to run this daemon by default?
>>
>> Because users want to listen to audio.
>>
>> > my thinking is by having the service off by default would reduce the
>> > default attack surface of the OS ?
>>
>> How big is that attack surface? And especially compared to X?
>>
>> > perhaps the installer could use the answer to the question do you
>> > intend to run X   to determine whether or not to enable the sndiod
>> > daemon ?
>>
>> The difference is that a running sndiod is not noticable to you. Running X
>> is - you dont have a console anymore on your screen.
>>
>> Whereas a not running sndiod is noticable - no sound.
>>
>> Next to security, we try to make it easy for people to use OpenBSD. Not
>> asking questions when not needed is just that.
>>
>> /Benno
>
>
>
> --
> Kindest regards,
> Tom Smyth.



--
Kindest regards,
Tom Smyth.

Reply | Threaded
Open this post in threaded view
|

Re: sndiod on by default (does it need to be ? )

Jean-Pierre de Villiers
If you are planning to deploy many systems in the near future and your
deployment script is very invovled then you might want to consider
building your own release and using that to install instead.

This way you don't need to append your deployment script to either
/install.site or /etc/rc.firsttime each time you install a new system.

Sincerely,
Jean-Pierre

On 21/02/21 05:34pm, Tom Smyth wrote:

> Hi folks,
> thanks for everyone who replied on and off list,
> I had not considered the console only user who uses audio also...
> (I had not even considered this  so pardon my ignorance folks,
> and thanks to Sebastian, Abel, and David for replying on and off list
>
> I guess Ill just add rcctl disable sndiod to my deploy ment scripts
> for my use cases :)
>
> Thanks again to all who considered it
>
> :)
>
>
>
> On Sun, 21 Feb 2021 at 14:28, Tom Smyth <[hidden email]> wrote:
> >
> > Hi Sebastian
> > I get users want to listen to audio but if the only hardware is a buzzer and the user is not running x what are the chances they are using audio on the console only ?
> >
> > I can keep running
> > rcctl disable sndiod
> > Post install
> >
> > I thought linking audio support on by default to x would make sense as it is likely such system is for users who may need audio
> >
> > Just a thought
> > Thanks
> >
> >
> > On Sunday, 21 February 2021, Sebastian Benoit <[hidden email]> wrote:
> >>
> >> Tom Smyth([hidden email]) on 2021.02.21 04:08:48 +0000:
> >> > Hello,
> >> >
> >> > I was wondering should sndiod (default) startup be determined based on
> >> > whether or not
> >> > it the install is a typical headless install (off) or  an install for
> >> > a user machine with  running X
> >> >
> >> > is there a reason why one would need to run this daemon by default?
> >>
> >> Because users want to listen to audio.
> >>
> >> > my thinking is by having the service off by default would reduce the
> >> > default attack surface of the OS ?
> >>
> >> How big is that attack surface? And especially compared to X?
> >>
> >> > perhaps the installer could use the answer to the question do you
> >> > intend to run X   to determine whether or not to enable the sndiod
> >> > daemon ?
> >>
> >> The difference is that a running sndiod is not noticable to you. Running X
> >> is - you dont have a console anymore on your screen.
> >>
> >> Whereas a not running sndiod is noticable - no sound.
> >>
> >> Next to security, we try to make it easy for people to use OpenBSD. Not
> >> asking questions when not needed is just that.
> >>
> >> /Benno
> >
> >
> >
> > --
> > Kindest regards,
> > Tom Smyth.
>
>
>
> --
> Kindest regards,
> Tom Smyth.
>

Reply | Threaded
Open this post in threaded view
|

Re: sndiod on by default (does it need to be ? )

Stuart Henderson
In reply to this post by Tom Smyth
On 2021-02-21, Tom Smyth <[hidden email]> wrote:
> my thinking is by having the service off by default would reduce the
> default attack surface of the OS ?

The attack surface is tiny.

sndiod has a pair of processes each run as their own dedicated uid, one
in a chroot jail containing no files and pledged to not allow access to
read/write files anyway, the other (which needs to access audio-related
nodes in /dev) using unveil to restrict itself to only the necessary
ones. The pledges are very restrictive. No network access unless you use
-L to enable the network server.

I don't honestly think it's worth going to the trouble of disabling.
Look at the other software you run which isn't enabled in OpenBSD by
default - that's where your attack surface is ;)


Reply | Threaded
Open this post in threaded view
|

Re: sndiod on by default (does it need to be ? )

Tom Smyth
Thanks Stuart, appreciate your time on this,   and explanation of
the sndiod design

it was a case of I dont understand, dont use so I just disable.
and then I proceeded to ask out of turn shouldn't everyone else disable because
I dont understand or use it my self :/

Re attack surface / risk of other software that I use on top of OpenBSD
 I couldn't agree more with you

Thanks again..

On Sun, 21 Feb 2021 at 18:42, Stuart Henderson <[hidden email]> wrote:

>
> On 2021-02-21, Tom Smyth <[hidden email]> wrote:
> > my thinking is by having the service off by default would reduce the
> > default attack surface of the OS ?
>
> The attack surface is tiny.
>
> sndiod has a pair of processes each run as their own dedicated uid, one
> in a chroot jail containing no files and pledged to not allow access to
> read/write files anyway, the other (which needs to access audio-related
> nodes in /dev) using unveil to restrict itself to only the necessary
> ones. The pledges are very restrictive. No network access unless you use
> -L to enable the network server.
>
> I don't honestly think it's worth going to the trouble of disabling.
> Look at the other software you run which isn't enabled in OpenBSD by
> default - that's where your attack surface is ;)
>
>


--
Kindest regards,
Tom Smyth.

Reply | Threaded
Open this post in threaded view
|

Re: sndiod on by default (does it need to be ? )

Raul Miller
In reply to this post by Stuart Henderson
On Sun, Feb 21, 2021 at 1:38 PM Stuart Henderson <[hidden email]> wrote:
> I don't honestly think it's worth going to the trouble of disabling.
> Look at the other software you run which isn't enabled in OpenBSD by
> default - that's where your attack surface is ;)

Also look at your hardware, and look at the documentation on the
software you're using.

Unless your concern is malware specifically targeted at your
environment, the consequences of being hit by malware probably aren't
going to be too far away from the consequences of running on faulty
hardware and/or not understanding your software.

(Malware specifically targeted at your environment would most likely
be motivated along the lines of discrediting you and/or your efforts.
And that's usually more easily accomplished using other methods, like
capitalizing on your most obvious mistakes.)

(If your concern is protection of trade secrets or loss of critically
important information: ink on paper does a pretty good job of holding
comprehensible information, and it has an attack surface which is
quite small, etc. But mostly, if those are concerns for you, it's
going to be about the people you're working with, and their
motivations. Also, mostly: NASA is a much better source of good
technical information, for those who want that.)

("Don't worry about people stealing an idea. If it's original, you
will have to ram it down their throats." -- Howard H. Aiken)

Anyways, the point I am trying to make here is that you're going to
notice some problems too late (so having plans for dealing with
failures is good, and having a variety of ways of isolating failures
is good).

That said: planning for the wrong disaster is usually better than not
planning for any disasters.

Good luck,

--
Raul