Re: sndiod on by default (does it need to be ? )
On Sun, Feb 21, 2021 at 1:38 PM Stuart Henderson 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
Re: sndiod on by default (does it need to be ? )
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 wrote: > > On 2021-02-21, Tom Smyth 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.
Re: sndiod on by default (does it need to be ? )
On 2021-02-21, Tom Smyth 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 ;)
Re: sndiod on by default (does it need to be ? )
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 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 wrote: > >> > >> Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > >> > 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. >
Re: sndiod on by default (does it need to be ? )
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 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 wrote: >> >> Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: >> > 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.
Re: sndiod on by default (does it need to be ? )
On Sun, Feb 21, 2021 at 8:39 AM Tom Smyth 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 > wrote: > > > Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > > > 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. >
Re: sndiod on by default (does it need to be ? )
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 wrote: > Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > > 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.
Re: sndiod on by default (does it need to be ? )
Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > 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
sndiod on by default (does it need to be ? )
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.
