Re: CVS commit: src/etc
Date:Mon, 14 Jan 2019 11:59:51 +1100 From:matthew green Message-ID: <10889.1547427...@splode.eterna.com.au> | i don't agree with this. | | if we were going to make things easy for naive users I didn't say "easy" for naive users, I said "most useful". That might mean "suitably secure" rather than "simply works" and is a different discussion. One possibility here, might be to make configuration classes, like "laptop" "workstation" "server" (whatever we want) and have different default configurations for different system types, so while I certainly wouldn't let non-root be configuring my servers in any way at all, I don't really want to be root in order to configure my laptop (at least to decide which wireless SSID it should connect to, or when wireless should be disabled when I am on a plane). We could also have different security levels, "locked down", "adequate", "better than nothing", and "absent" and have different default configurations for those as well. And then it would be easy for sysint to ask the user which type of system this is (it would often be able to intuit a reasonable default from the config) and what level of security they want, and set those at the the same time it is setting rc_configured=YES. Aside from working out exactly what the values for the various configs should be for whatever different modes we create, all of this is trivial. kre
Re: CVS commit: src/etc
matthew green writes: > (i wouldn't pick 'wheel' as this group -- i would invent a > new group either called 'net' or 'wpa', with no underscore > since they're designed to be assigned, unlike the groups > for specific programs security models.) Are you saying that you are ok with the following: add a new group "net" by default, nobody is in it it's ok for things that modify networking config to allow this to be done by users in group net, in addition to root (so therefore, absent configuration by root, there are no additional privileges compared to now) ? If so, that seems like a reasonable compromise compared to letting wheel modify networking, and calling it "net" lets this be a logical privilege in general, even if wpa config is the only thing right now.
Re: CVS commit: src/etc
> On Jan 13, 2019, at 5:08 PM, David Holland > wrote: > > Is there a way we could, for example, leverage the current hacks for > chowning console devices to grant access to wpa_supplicant? Some of this could be achieved with ttyaction(5), certainly. -- thorpej
Re: CVS commit: src/etc
On Mon, Jan 14, 2019 at 09:42:54AM +1100, matthew green wrote: > it would be OK if this was _read-only_ access to network > configuration, but one should never be allowed to change the > it unless root. In the long run, it's quite helpful for laptops to be able to adjust the network configuration from a GUI on the console without having to run GUI bits as root. We aren't in a position to do this correctly (nor does importing the likes of polkit as a hack to allow reasoning about being "on the console" constitute correctly) but let's not lose track of it as a goal. Is there a way we could, for example, leverage the current hacks for chowning console devices to grant access to wpa_supplicant? -- David A. Holland dholl...@netbsd.org
re: CVS commit: src/etc
> | i don't want to allow [...] > > People, once again, a big meaningless discussion on what the > default configuration should be.We should work out what will > be most useful to most naive users, and make that be the default, > regardless of what any of us want. i don't agree with this. if we were going to make things easy for naive users we'd give up almost any pretense of security at all. i'm not talking about general configuration, but security configuration. AFAICT, we care a lot about security. allowing network configuration to be done by some new class of users is not what i consider a secure default. at the very least, this point must be considered and chosen, rather than some contested commit enabling it. infact, i was trying to say it would be great if this worked better out of the box -- but i don't see why non-root should be allowed to change network configuration by default. wheel is a stepping stone in the security layering, please don't skip over it. .mrg.
Re: CVS commit: src/etc
In my previous message, I forgot to also note that if modifying (if required) wpa_supplicant to create the socket with the ownership & permissions set in the rc.conf file is too hard (would create issues with importing new versions easily) then the same can be accomplished by putting the socket in a sub-dir (it is already I believe) and applying the permissions to the gating directory, then the socket just needs to be made 666 mode and we're all happy. And incidentally, why is (even before the recent changes, I haven't updated to those in systems I use yet) the socket created 770 mode ? What does 'x' mean to a socket? Does that have some magic meaning I'm unaware of, or is this just sloppy? kre
re: CVS commit: src/tests/kernel
> Modified Files: > src/tests/kernel: t_timeleft.c > > Log Message: > add call error checks, requested by mrg@ thanks!
Re: CVS commit: src/etc
Date:Mon, 14 Jan 2019 09:42:54 +1100 From:matthew green Message-ID: <11338.1547419...@splode.eterna.com.au> | > I suppose the real question is do we want to allow group access to | > [...] | i don't want to allow [...] People, once again, a big meaningless discussion on what the default configuration should be.We should work out what will be most useful to most naive users, and make that be the default, regardless of what any of us want. For the rest of us, what we need is the ability to configure to suit our own desires. So perhaps an rc.conf setting like WPA_MODES=077:user:group or something, to select the umask to use when creating the socket (or the inverse to set the perms) and the user and group that should own it. Then just decide what is best to set that to for the default config, and everyone here can adjust as needed in our own systems. For my personal preference (not to be considered when deciding what is the default setup) I'd prefer wheel group to be able to config the (wireless) network (which is all that is in question here, right? nothing is allowing non-root to edit rc.conf or /etc/ifconfig.xx0) On my phone I don't need to be root to decide which wireless net to connect to, I can't imagine why I would need to be on my laptop. But to each their own (ie: there is no need for anyone to explain why they prefer what they prefer for their systems ... just stop demanding that the default config be what you want on your system.) I prefer wheel as the group, over creating a new one, not because a new one is much harder to deal with, but if we keep creating new specific groups (that people actually join, unlike the _ groups) then eventually we'll reach the point where some users need to be in more than NGROUPS groups, and things stop working (and as I recall, NGROUPS being exceeded does not result in any obvious feedback). kre
re: CVS commit: src/tests/kernel
On Jan 14, 9:29am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/tests/kernel | "Christos Zoulas" writes: | > Module Name:src | > Committed By: christos | > Date: Sun Jan 13 15:36:57 UTC 2019 | > | > Modified Files: | > src/tests/kernel: t_timeleft.c | > | > Log Message: | > Increase the timeout a bit, and make sure we join so that there is no | > race. | | i notice both pthread_kill() and pthread_join() calls here do | not have their return value checked. | | any particular reason? shouldn't their failiure also be a | test failure? Nope, I will add them. christos
re: CVS commit: src/etc
Roy Marples writes: > On 13/01/2019 10:20, matthew green wrote: > > shouldn't one need to be root to modify network configuration? > > i shouldn't be able to tell wpa_supplicant to do something as > > non-root, in a default install. > > In a default install the only member of wheel is root and wpa_supplicant > is not started. > > I suppose the real question is do we want to allow group access to > wpa_supplicant and if so which group if not wheel? > > If we don't want to allow group access I may as well revert my changes > and setup is then as before - the user is expected to configure > everything themselves and wpa_cli won't work by default. This would be a > shame as I've had a lot of positive feedback on this change already. i don't want to allow configuration changes by non root. that should be fairly obvious and not something anyone would question. group 'wheel' means access to root, not that it gives you additional privs immediately. if it did there would be no point in having group 'wheel' -- may as well just make all the wheel users uid 0, since that is the security provided. it would be OK if this was _read-only_ access to network configuration, but one should never be allowed to change the it unless root. ie, i'm not objecting to having a better default wpa_supplicant configuration, but don't remove security layers in the process. (i wouldn't pick 'wheel' as this group -- i would invent a new group either called 'net' or 'wpa', with no underscore since they're designed to be assigned, unlike the groups for specific programs security models.) .mrg.
re: CVS commit: src/tests/kernel
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Sun Jan 13 15:36:57 UTC 2019 > > Modified Files: > src/tests/kernel: t_timeleft.c > > Log Message: > Increase the timeout a bit, and make sure we join so that there is no > race. i notice both pthread_kill() and pthread_join() calls here do not have their return value checked. any particular reason? shouldn't their failiure also be a test failure? .mrg.
Re: CVS commit: src/etc
Jason Thorpe writes: >> On Jan 13, 2019, at 5:21 AM, Greg Troxel wrote: >> >> Even if you have to be root, these changes are still hugely useful. >> "sudo wpa_cli" is not that hard, even if it seems like it should not be >> necessary. > > ...but made slightly more annoying seeing as how sudo is not part of the base > OS. s/sudo wpa_cli/su root -c wpa_cli/ But yes, it is harder. I had to read the su man page (back when I was young, we didn't have sudo and had to use su uphill both ways after toggling in the boot loader).
Re: CVS commit: src/etc
> On Jan 13, 2019, at 5:21 AM, Greg Troxel wrote: > > Even if you have to be root, these changes are still hugely useful. > "sudo wpa_cli" is not that hard, even if it seems like it should not be > necessary. ...but made slightly more annoying seeing as how sudo is not part of the base OS. -- thorpej
Re: CVS commit: src/etc
Roy Marples writes: > On 13/01/2019 10:20, matthew green wrote: >> shouldn't one need to be root to modify network configuration? >> i shouldn't be able to tell wpa_supplicant to do something as >> non-root, in a default install. > > In a default install the only member of wheel is root and > wpa_supplicant is not started. > > I suppose the real question is do we want to allow group access to > wpa_supplicant and if so which group if not wheel? That is indeed the real question. As I see it wheel has historically been a group for users that are system administrators, given how "su" only allows users in wheel to su. So it seems reasonable to allow various configuration changes by users in wheel. It seems the only point in putting somebody in wheel now is if you tell them the root pw, to let them su. Are there other reasons? Another approach is to create a wpa_supplicant group, and allow wpa changes by those in that group. I can't see any reasonable objection to this, other than group bloat. > If we don't want to allow group access I may as well revert my changes > and setup is then as before - the user is expected to configure > everything themselves and wpa_cli won't work by default. This would be > a shame as I've had a lot of positive feedback on this change already. Even if you have to be root, these changes are still hugely useful. "sudo wpa_cli" is not that hard, even if it seems like it should not be necessary.
re: CVS commit: src/etc
shouldn't one need to be root to modify network configuration? i shouldn't be able to tell wpa_supplicant to do something as non-root, in a default install. .mrg.
Re: CVS commit: src/etc
Not really, it just sets the group explicitly rather than implicitly. Without it the socket group is derived from the directory it's created in, which is group wheel to start with. Now it could be argued that creating the socket in the first place allows members of the wheel group to configure wpa_supplicant and thus connect to a network. I don't see this as a problem myself and I believe that wpa_cli should work by default if wpa is enabled. Roy On 12 January 2019 19:05:23 GMT, m...@netbsd.org wrote: >This lets any user in wheel group choose to connect to the network. >Isn't that more privileges than we normally give? > >On Sat, Jan 12, 2019 at 04:51:55PM +, Roy Marples wrote: >> +ctrl_interface_group=wheel -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
