**** BEGIN LOGGING AT Thu Oct 01 02:59:57 2020
Oct 01 05:06:54 <mangix> LWN has an article on OpenWrt and SELinux
Oct 01 05:06:57 <mangix> wonder why
Oct 01 07:34:25 <aparcar[m]> I saw it, too
Oct 01 07:35:03 <aparcar[m]> I don't remember sharing this blog post any where but the github PR
Oct 01 07:39:41 <aparcar[m]> mangix: I think it happened multiple times that you merged a package bump before the official maintainer could comment. Please give it a few more days or maintainer will feel passed over and eventually stop take it seriously
Oct 01 07:54:12 <grift> in selinux-policy/files/selinux-config there is this: SELINUX=enforcing, i suggest that be changed to SELINUX=permissive for now
Oct 01 07:54:18 <grift> oops
Oct 01 07:55:35 <grift> but i just did a search on google "running openwrt with selinux", seems LWN is late if you see that
Oct 01 07:58:27 <aparcar[m]> in what way late?
Oct 01 08:04:39 <grift> well phoronix reported on it 3 jan 2020
Oct 01 08:05:02 <grift> https://www.phoronix.com/scan.php?page=news_item&px=OpenWrt-Better-Security-2020
Oct 01 08:06:26 <aparcar[m]> fair, however that was kind of far from becoming upstream
Oct 01 09:05:26 <grift> whydoes it seem odd to you?
Oct 01 09:09:36 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 99.7% packages reproducible in our current test framework.)
Oct 01 09:13:04 <mangix> looks like miska is having fun with github actions.
Oct 01 09:21:49 <aparcar[m]> yea I hope more people start some complex tests
Oct 01 09:22:45 <aparcar[m]> mangix: does openwrt support tclsh? https://github.com/redis/redis/blob/unstable/runtest
Oct 01 09:22:52 <aparcar[m]> that would be an actual runtime test :)
Oct 01 09:41:51 <mangix>  no idea
Oct 01 11:37:37 <olmari> Okay paulfertser isn't here ATM... I was wondering that if I'd take an shot on debugging the damned miniupnpd, I sure would appreciate some pointers and/or past experiences 🙂 I'm skilled with linux and servers, not that much actual deeper debugging :)
Oct 01 11:37:37 <olmari> So, I don't know is this question or query or what, but at least an comment :D
Oct 01 11:38:09 <olmari> I guess anyone can tell good practices, I just remeber that guy talking "giving up on miniupnpd" on past conversations, I could still remember eve nthat wrong :D
Oct 01 11:38:39 <PaulFertser> olmari: it wasn't me who gave up on it. I wouldn't be using PNP at all for anything ;)
Oct 01 11:39:26 <PaulFertser> olmari: my best pointer would be the ./scripts/remote-gdb and the corresponding page on the wiki. Using GDB this way really helps, and you do not need any special tricks to get debugging info.
Oct 01 11:40:11 <PaulFertser> So you can set breakpoints etc
Oct 01 11:41:20 <olmari> Aight, sounds sane enough at starters :)
Oct 01 11:41:58 <olmari> also, the dnssec did got fix, I'm compiling new master to test it tout, among other things
Oct 01 11:42:51 <olmari> (I know, I could cowboy-test fix too, but need other things too 🙂 )
Oct 01 11:44:18 <olmari> I guess if 6rd still ef's up on ifup completerly I'll try looking that first :D
Oct 01 11:45:28 <PaulFertser> olmari: I was upgrading my own device and I ended up fixing that dnsmasq script in exactly the same way :)
Oct 01 11:45:49 <olmari> hehe =)
Oct 01 11:49:43 <grift> i dumped some thoughts on SELinux on OpenWrt and the concern about some of the aspects of it (like maintainability and resources) https://defensec.nl/~kcinimod/owrt-selinux.html
Oct 01 12:32:56 <jow> rmilecki: got a bit further in debugging and it appears the cause is actually stupidly simple
Oct 01 12:34:14 <jow> rmilecki: mod ubus invokes ops->request_done() (uh_request_done()) when processing non-batched ubus requests
Oct 01 12:34:29 <jow> rmilecki: this confuses client.c's request lifecycle state machine
Oct 01 12:35:33 <jow> rmilecki: you ubus probe call (which issues a non-batched list request) simply exposes this bug early before all other page ressources are loaded
Oct 01 12:35:59 <jow> any subsequent requests scheduled on the same persistent connection which handles the prope request are then stalled
Oct 01 12:36:08 <jow> *probe
Oct 01 12:37:11 <jow> I've encountered two other weird things while debugging this which do not appear to contribute to this particular issue but which appear to be wrong nontheless
Oct 01 12:38:54 <jow> 1) unbalanced ref/unref: uh_ubus_send_list() invokes uh_client_unref() (ubus.c:661) which is then invoked again by its caller (ubus.c:799)
Oct 01 12:41:41 <jow> actually the second thing turned out to be a non-issue
Oct 01 12:41:56 <jow> still that unbalanced unref looks like it could lead to occasional segfaults
Oct 01 12:43:26 <rmilecki> jow: thanks a lot for looking at that
Oct 01 12:51:55 <jow> rmilecki: still found a definite fix, batched requests also call ops->request_done() eventually
Oct 01 12:52:35 <jow> rmilecki: however the diff between batched and unbatched cases seems to be that batched, working ones invoke ops->request_done() from within an uloop timeout callback while unbatched ones invoke it synchroneously
Oct 01 12:53:03 <jow> this likely prevents some other, interleaved state handlers from executing
Oct 01 12:53:17 <jow> *still not found
Oct 01 12:54:12 <jow> indeed, that makes it work
Oct 01 13:00:31 <jow> rmilecki: this fix appears to work for me, it solves the connection stalls: http://sprunge.us/81KU3G
Oct 01 13:01:01 <jow> rmilecki: various error paths in ubus.c still invoke ops->request_done() synchroneously though, I suppose those need to be converted as well
Oct 01 13:01:53 <rmilecki> jow: i'll test it a bit later, it's a busy day for me
Oct 01 13:02:06 <jow> sure, np
Oct 01 13:57:14 <adrianschmutzler> Hi, I just wondered:
Oct 01 13:57:28 <adrianschmutzler> does it still make sense to enable 802.11b rates _by default_ in 2020?
Oct 01 13:58:18 <adrianschmutzler> or wouldn't it be time so set legacy_rates = 0 by default?
Oct 01 14:00:29 <DonkeyHotei> does it hurt to have them on?
Oct 01 14:01:56 <adrianschmutzler> as far as I understand it, have b rates enabled will cause reduced performance for the "higher" modes
Oct 01 14:02:48 <adrianschmutzler> (more overhead with b)
Oct 01 14:03:07 <DonkeyHotei> on 2.4ghz only, so does it really make a huge diff?
Oct 01 14:03:28 <olmari> A little vague here, but it might not be rates themselves. but generally the support for 11b-rates makes rest of things slower because need to "wait" more in order to make sure 11b clients can get through
Oct 01 14:03:49 <adrianschmutzler> certainly not a huge diff, but how many b-only devices will be out there
Oct 01 14:04:19 <adrianschmutzler> and you can just tick it on if you want it, I'm just discussing the default setting
Oct 01 14:04:28 <olmari> in some broader extent, it applies to all older vs newer techs
Oct 01 14:04:50 <DonkeyHotei> i think the current default is fine
Oct 01 14:05:58 <olmari> indeed B went extinct relatively fast when G came out... G then is still around occasionall on brand new devices still (damned automatic vacuum 😀 )
Oct 01 14:06:09 <lemmi> DonkeyHotei: b uses different modulation and therefore uses 22Mhz bandwidth channels instead of 20Mhz
Oct 01 14:07:59 <DonkeyHotei> but if you have no b clients, the gain from disabling it is still marginal, considering it's still 2.4ghz
Oct 01 14:08:01 <lemmi> this makes a difference in europe, since 13 channels are available. with channels 1/5/9/13 you can have 4 non-overlapping channels when dropping support for b
Oct 01 14:08:43 <lemmi> otherwise you need to spread to 1/6/11 or something similar
Oct 01 14:10:09 <lemmi> and since b is effectivly dead, i think it's a reasonable thought to switch the default
Oct 01 14:10:34 <DonkeyHotei> people still use 1/6/11 on g and even n
Oct 01 14:10:44 <olmari> well.. TBH personall I don't think default matters that much.. matters more such option exist :)
Oct 01 14:10:52 <DonkeyHotei> agreed
Oct 01 14:11:00 <Borromini> i have had disconnection issues with older bgn clients, after i disabled 802.11bwith legacy_rates = 0
Oct 01 14:11:25 <DonkeyHotei> yeah, i'd keep it on
Oct 01 14:11:38 * lemmi has it disabled everywhere
Oct 01 14:11:53 <Borromini> it took me a while to figure out why older ath9k windows devices were getting shut out of the network
Oct 01 14:12:11 <lemmi> i might still have some old relics, but i doubt there are drivers for it
Oct 01 14:12:14 <adrianschmutzler> how old are those?
Oct 01 14:12:37 <adrianschmutzler> even my b/g notebook from 2006 works with b disabled here
Oct 01 14:12:38 <DonkeyHotei> Borromini: so, draft-n devices?
Oct 01 14:12:52 <Borromini> DonkeyHotei: i have no clue. friend's stuff.
Oct 01 14:13:12 <Borromini> but apparently one of those recently died and he said it was 9 years old, with a straight face
Oct 01 14:13:27 <DonkeyHotei> 2011
Oct 01 14:20:19 <Borromini> i wouldn't disable it by default. one can always recommend it on the wiki, or in luci
Oct 01 14:20:40 <Borromini> but i predict plenty of 'openwrt 20.xx broke my wireless' topics if it gets enforced
Oct 01 14:21:37 <owrt-snap-builds> build #460 of ipq40xx/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/460  blamelist: Paul Spooren <mail@aparcar.org>
Oct 01 14:22:22 <adrianschmutzler> and that's what I actually ask myself: if those are many, we should keep it, if those are few, we should disable by default
Oct 01 14:22:42 <adrianschmutzler> and keep in mind that this will only affect users with fresh config, which will also reduce the number of affected people
Oct 01 14:26:07 <lemmi> wow. draft-n has been around for 14 years.
Oct 01 14:31:52 <Slimey> :)
Oct 01 14:33:01 <Borromini> lemmi: tell that to OEMs and ODMs eh.
Oct 01 14:33:37 <Borromini> or even more recently, all those people who bought Marvell gear and are now left with dead drivers that won't ever do wpa3 e.g.
Oct 01 14:33:45 <Borromini> and that for top shelf (and top dollar) devices;
Oct 01 14:36:39 <Borromini> all this hardware is running win10 mind you, but of course those wireless drivers are often whatever the manufacturer bothered to offer or update at some point. so...
Oct 01 14:52:04 <Slimey> APs 443 Clients 1810
Oct 01 14:52:04 <Slimey> 30% (550) are gn 2.4ghz users
Oct 01 14:52:04 <Slimey> 70% (1260) are acn 5ghz users
Oct 01 14:52:19 <Slimey> no b at all turned it off years ago
Oct 01 14:58:56 <blocktrron> A lot of wireless printers / MFCs and IoT devices (Panasonic A/C) still do 802.11b only.
Oct 01 14:58:58 <karlp> what sort of site is that?
Oct 01 15:00:02 <Borromini> blocktrron: yeah.
Oct 01 15:00:22 <Borromini> looked for one that supported wireless and still just seem to do 802.11g
Oct 01 15:32:05 <olmari> Minor discrepancy I've spotted on luci wireless settings... it does expose "Allow legacy 802.11b rates" on 5GHz too.... which can't obviously be true... then again I don't know what that settings _really_ does, if itis other legacy stuff too, just named that way :)
Oct 01 16:10:49 <olmari> oh hey... I do remember talk about DDNS changes, but under where in menuconfig (or other means) I can actually define what provider to include now, searching of "ddns" did not yield anything in menuconfig, in current master
Oct 01 16:23:57 <olmari> nor searching provider name :)
Oct 01 16:25:57 <olmari> oh... propably "service"
Oct 01 16:26:08 <olmari> "Common ddns providers"
Oct 01 16:27:40 <olmari> damn... I think ddns-scripts stuff is literally ongoing... I see changes relating in feeds update... after I did such not 2 hours ago =)
Oct 01 16:42:40 <jow> rmilecki: okay, I think I fully nailed that timeout bug now, just took me some time to understand why the proposed fix works
Oct 01 17:17:23 <giaco> hello! I'm trying to understand how the automated bulding pipeline works. I ended up comparing the stable branch updates here https://github.com/openwrt/packages/commits/openwrt-19.07, the buildbot page here https://buildbot.openwrt.org/openwrt-19.07/packages/console, and the repository here https://downloads.openwrt.org/releases/packages-19.07/mips_mips32/packages/ , but I can't wrap my
Oct 01 17:17:25 <giaco> head around how/when the successfull builds gets to the repository. Do you have any idea?
Oct 01 17:17:53 <karlp> ~daily
Oct 01 17:20:06 <giaco> karlp: is it a separate process from the buildbot, like a cron job, or what?
Oct 01 17:23:03 <karlp> no idea, it's something like buildbot runs daily, pushes files as jobs finish.
Oct 01 17:23:14 <karlp> is there a problem, or are you trying to replicate it, or what?
Oct 01 17:23:47 <karlp> have you read through here: https://git.openwrt.org/?p=buildbot.git;a=tree ?
Oct 01 17:26:29 <jow> buildbot will rsync the files after each run
Oct 01 17:28:58 <jow> rmilecki: final fix proposal here: http://sprunge.us/DZ1Mqu
Oct 01 17:29:35 <jow> rmilecki: so after all your assumption was correct, that ubus list request you introduced in the middle of all those other requests triggered an invalid state machine transition in uhttpd
Oct 01 17:32:52 <giaco> karlp: no, just trying to understand why successfull build is not yet in repo
Oct 01 17:33:55 <karlp> which commit are you chasing?
Oct 01 17:35:52 <karlp> https://buildbot.openwrt.org/openwrt-19.07/packages/builders/mips_mips32 says your mips r32 isn't finished yet...
Oct 01 17:36:03 <karlp> and needed a retry after a glitch
Oct 01 17:36:30 <giaco> karlp: this https://github.com/openwrt/packages/commit/a661e8d248e650e6953cf2eb56b6f4d72fc23add
Oct 01 17:37:04 <karlp> that's in #407 that errored, presumably will be in #408 which is still in process then.
Oct 01 17:37:24 <giaco> karlp: I see now it failed before current build, but. But I don't get the error
Oct 01 17:37:40 <jow> build timed out
Oct 01 17:37:53 <jow> too much time elapsed without new output
Oct 01 17:38:38 <giaco> I guess is a workaround to solve real problem?
Oct 01 17:38:48 <jow> hm?
Oct 01 17:39:10 <jow> the build coordinator is in europe, the build worker in the us west coast, the connection between them is frequently having issues
Oct 01 17:39:49 <jow> last time it seemd the connection timed out, eventually the build coordinator gave up, terminated the build cycle and rescheduled it
Oct 01 17:40:05 <jow> it is not related to your commit or any particular bug
Oct 01 17:40:45 <giaco> ah ok, that's the anwer I was trying to figure out. Thanks. I'll wait next bake
Oct 01 17:41:36 <jow> :)
Oct 01 17:53:16 <jow> nbd: ping
Oct 01 17:59:12 <jow> nbd: unping
Oct 01 18:04:38 <aparcar[m]> jow: could you please vote
Oct 01 18:05:35 <aparcar[m]> giaco: are you flynn-org?
Oct 01 18:12:22 <grift> aparcar[m]: in make menuconfig theres an option to create a build image, it creates a build image, is that usable?
Oct 01 18:13:02 <grift> i mean  will i be able to for example use opkg in images created with that?
Oct 01 18:16:27 <grift> s/build image/image builder image/
Oct 01 18:19:08 <aparcar[m]> grift: yes
Oct 01 18:19:19 <aparcar[m]> just drop your policy in the packages folder of the imagebuilder
Oct 01 18:20:24 <grift> thanks, i just ordered a linksys m8300 to tinker with and create an image builder for it so i guess ill be tinkering tomorrow
Oct 01 18:20:54 <aparcar[m]> jow: thanks
Oct 01 18:43:56 <aparcar[m]> jow: to read the Source folder of a package control file, is there a better way than `sed -ne 's#^Source: .*/\(.*\)$#\1#p' ./control`?
Oct 01 18:45:57 <jow> depends on where you want to read it, but my first tool of choice would be sed as well
Oct 01 18:50:24 <aparcar[m]> in the packages test ci. I think sed is just fine for this job
Oct 01 18:50:25 <aparcar[m]> thanks again
Oct 01 19:07:08 <jow> nbd: re-ping
Oct 01 19:16:18 <aparcar[m]> can prepare_rootfs get a list of folders to include?
Oct 01 19:31:42 <jow> nbd: so I was testing your bridge vlan op patches but they do not appear to have the desired effect for me
Oct 01 19:33:24 <jow> nbd: I tested the following configuration: https://pastebin.com/X5MtUL1t and wlan0 / wlan1 are not added to the switch0 bridge
Oct 01 19:34:49 <jow> nbd: ah! it works with "option ifname switch0" in interface lan but not with "option ifname switch0.1"
Oct 01 19:35:13 <jow> I guess the hotplug ops are not inherited for implicit 802.1q ifaces
Oct 01 19:35:21 <jow> only for explicit ones
Oct 01 19:35:55 <aparcar[m]> grift: https://lwn.net/Articles/833248/ :)
Oct 01 19:43:29 <Borromini> lovely :P
Oct 01 19:43:47 <grift> aparcar[m]: yes selinux can be intimidating
Oct 01 19:44:06 <grift> well let me rephrase, linux can be intimidating and selinux exposes that
Oct 01 19:45:01 <grift> anyway's i am familiar with this sentiment, so not shocked or anything
Oct 01 19:46:26 <grift> anyway i think they misunderstand
Oct 01 19:47:00 <grift> i kind of see this endeavor like debian, debian works great with selinux but they dont use it by default
Oct 01 19:47:26 <grift> i think thats probably a good approach for openwrt as well (at least for now)
Oct 01 19:47:40 <grift> where you just provide the option
Oct 01 19:48:09 <grift> in debian switching to selinux is a breeze
Oct 01 19:48:25 <grift> and no one is complaining or threatening to fork (LOL)
Oct 01 19:48:50 <grift> anyway nothing wrong with a fork (if it lasts, talk is cheap)
Oct 01 19:54:46 <grift> the matrix analogy has kind of lost its power due to recent abuse by the likes of elon Musk but ive used it for quite some time when it comes to selinux
Oct 01 19:55:05 <grift> theres blue-pill people and red-pill people
Oct 01 19:55:36 <grift> people that want to know the reality of what goes on in their systems and people that rather not know
Oct 01 19:56:25 <grift> and the people that rather be ignorant feel uneasy about the idea that they have to deal with selinux and be confronted with reality of all the complexities of their systems
Oct 01 19:58:46 <grift> i feel helpless with something like selinux, knowing theres a plethory operations going on behind my back and i have no way to control it
Oct 01 19:58:55 <grift> s/with/without/
Oct 01 20:20:18 <grift> tell you one thing if anyone, then the people who designed luci would be able to make selinux understandable and easy to use
Oct 01 20:20:57 <grift> i am amazed at how well that interface presents those complexities in way's that are easy to use
Oct 01 20:25:34 <aparcar[m]> yea shout out to jow I guess
Oct 01 20:37:53 <Grommish_> I can't read it until next week.  Which group is fitting?
Oct 01 20:39:30 <grift> comments are public
Oct 01 20:39:38 <Grommish> I meant in the article
Oct 01 20:39:50 <Grommish> Because why would anyone complain about someone else doign the hard work to increase security
Oct 01 20:39:58 <Grommish> It's.. beyond me
Oct 01 20:40:44 <Grommish> So, i was curious as to if the article itself was doing the complaining, or just the randoms in the comments
Oct 01 20:40:53 <grift> well i can understand it, if youre passionate about something , its feels threatening
Oct 01 20:41:23 <Grommish> For the vast majority of users, it would be transparent
Oct 01 20:41:47 <Grommish> So, someone just doesn't want to learn a skill set?
Oct 01 20:41:55 <grift> yes you know it i know it but they dont and its kind of like a black out moment for some
Oct 01 20:42:10 <Grommish> Ah
Oct 01 20:42:11 <grift> like a fit
Oct 01 20:42:34 <Grommish> I'm the first to admit I know nothing about it.. but if I hard, it can't be that hard
Oct 01 20:42:50 <Grommish> err if I hard to
Oct 01 20:42:54 <grift> might have been some traumatic past experience that causes a snap effect
Oct 01 20:42:55 <Grommish> ...
Oct 01 20:42:58 <Grommish> had.
Oct 01 20:47:52 <grift> in theory selinux is excelent for openwrt (for me it is)
Oct 01 20:48:14 <grift> i hardly every look after my router, it just has to do its job
Oct 01 20:48:18 <Grommish> You'd think limiting access on an exposed device would be a good thing
Oct 01 20:48:40 <Grommish> Does it just break things in general?
Oct 01 20:48:55 <grift> it shouldnt but it could yes
Oct 01 20:48:58 <Grommish> Or is it just a matter of time to build out the list and include the outliers
Oct 01 20:49:24 <grift> it all depends but generally selinux is used to enforce least privilege
Oct 01 20:49:33 <grift> but as software evolves privileges change
Oct 01 20:49:55 <Grommish> How does that mix with the fact openwrt uses root
Oct 01 20:49:56 <grift> and so its prone to lose synchronization
Oct 01 20:50:26 <grift> but take my scenario i cant remember when i last booted my router
Oct 01 20:50:36 <grift> let alone update it
Oct 01 20:50:57 <grift> i dont like thinking about having to update it then having to redo my customizations
Oct 01 20:51:01 <grift> i need to stay online
Oct 01 20:51:11 <grift> and so selinux gives me some piece of mind
Oct 01 20:51:14 <Grommish> Right..  You do it if you have to and not before hand
Oct 01 20:51:39 <Grommish> I'm all for hardening of a device
Oct 01 20:51:40 <grift> and since nothing changes , selinux doest have to change either
Oct 01 20:51:56 <grift> and so for me after the rough edges are ironned out it should just work
Oct 01 20:52:14 <grift> but theres also a different audience
Oct 01 20:52:24 <grift> people that want to tinker
Oct 01 20:52:26 <Grommish> Is there an easy to add policy?
Oct 01 20:52:44 <grift> and then selinux could be painful (but selinux should always be an option)
Oct 01 20:52:54 <grift> define easy
Oct 01 20:53:09 <grift> you would have to reflash the device for any policy changes
Oct 01 20:53:16 <Grommish> Well..  you know what OpenWrt has from the buildbot .config file
Oct 01 20:53:30 <Grommish> Those don't change.. or do so rarely
Oct 01 20:53:50 <Grommish> Can you policy for that as a starting poing?
Oct 01 20:54:06 <Grommish> Can you pre-define policy groups with specific roles?
Oct 01 20:54:22 <Grommish> That packages can just hook to?
Oct 01 20:54:23 <grift> sure but its kind of counter intuitive
Oct 01 20:54:37 <grift> because the implies not least privilege
Oct 01 20:54:44 <grift> because that stuff isnt generic
Oct 01 20:54:45 <Grommish> It won't be.. for those polcies
Oct 01 20:54:53 <Grommish> But for the core stuff, it would be very specific
Oct 01 20:55:03 <grift> yes you could create rough templates
Oct 01 20:55:07 <Grommish> The generic policies can be used as a migration point
Oct 01 20:55:19 <Grommish> but the core doesn't change.. or does so predictiably
Oct 01 20:55:28 <Grommish> or in a way it's broken on master and poeple can't complain
Oct 01 20:55:36 <grift> but my policy is even more radical in that respect, it just say's i target these common entities and everything has free reign
Oct 01 20:55:42 <Grommish> because they aren't suppose to be using master anyway hehe
Oct 01 20:56:33 <grift> so in theory you could have a policy that could benefit and at the same time not be a "pain in the ass"
Oct 01 20:56:38 <grift> but thats theory
Oct 01 20:56:46 <Grommish> So you're setting up a watchlist rather than a control policy
Oct 01 20:57:05 <Grommish> If that is what you're saying, it'll sell easier if you put it that wya
Oct 01 20:57:27 <grift> i am targeting a selection of processes only
Oct 01 20:57:41 <Grommish> Right.. a watchlist of vulnerable processes
Oct 01 20:57:50 <Grommish> and exerting extra control over them
Oct 01 20:57:56 <Grommish> Completely reasonable :)
Oct 01 20:57:59 <grift> yes but even that is hard
Oct 01 20:58:17 <grift> so lets say openwrt has like 10 processes in a bbasic setup
Oct 01 20:58:46 <grift> theres a bunch of them that cannot fully be contained because they do stuff on behalf of the user
Oct 01 20:59:11 <grift> for example dropbear runs a shell on your behalf when you log in and you dont want to be targeted
Oct 01 20:59:21 <grift> then take something like hotplugcall
Oct 01 20:59:38 <grift> that thing needs to be able to do stuff on your behalf  when you hotplug
Oct 01 20:59:53 <grift> and i dont know before hand what people want to do on hotplugging
Oct 01 21:00:00 <grift> they do the silliet things
Oct 01 21:00:18 <grift> and then theres cron, which runs tasks on behalf of the user
Oct 01 21:00:20 <Grommish> I just realized dropbear runs as root.  I wonder if there is a reason it isn't in it's own user/group like dnsmasq
Oct 01 21:00:24 <Grommish> I'm sure there is a reason, but..
Oct 01 21:00:48 <grift> because it needs to setuid etc
Oct 01 21:01:06 <grift> (i suppose)
Oct 01 21:01:21 <Grommish> selinux would be able to grant just those without the rest?
Oct 01 21:01:36 <grift> anyways its complex situation but selinux didnt cause that it just helps use control it
Oct 01 21:01:51 <grift> yes but whats the point?
Oct 01 21:02:00 <grift> it can run a shell as you
Oct 01 21:02:10 <grift> but yes i do contain dropbear
Oct 01 21:02:19 <Grommish> it can run a shell as root
Oct 01 21:02:24 <grift> but i know that it could just run a shell and escape
Oct 01 21:02:25 <Grommish> but what if it was running a dropbear
Oct 01 21:02:45 <Grommish> could selinux grant the root access to certain tools but not others?
Oct 01 21:03:00 <grift> no
Oct 01 21:03:06 <Grommish> So it isn't that granular
Oct 01 21:03:07 <Grommish> Ok
Oct 01 21:03:26 <grift> selinux is an enhancement to linux access control
Oct 01 21:03:31 <grift> ie an addon
Oct 01 21:03:56 <grift> it sits below linux uid/gid modes  and is totally indepdendent
Oct 01 21:04:08 <grift> so it doesnt know about root at all
Oct 01 21:04:22 <grift> to selinux its all just entities
Oct 01 21:04:36 <grift> whether its joe or root it doesnt matter
Oct 01 21:04:46 <Grommish> ok, then coudl you tag the binary security for use with a given user?
Oct 01 21:04:54 <Grommish> or how do you check the entry
Oct 01 21:05:05 <Grommish> or rather, against what do you check it
Oct 01 21:05:12 <grift> basically its like this currently
Oct 01 21:06:11 <grift> when a process associated with the dropbear selinux identifier executes a file associated with the shell selinux identifier then the dropbear process identifier "transitions" to the "user" identifier automatically
Oct 01 21:06:19 <grift> and allow rules are associate with identifiers
Oct 01 21:06:37 <grift> so just by executing that shell file the permissions change
Oct 01 21:06:48 <grift> because the identifiers transition
Oct 01 21:07:00 <Grommish> Well, i was thinking more of the other end of the chain
Oct 01 21:07:23 <Grommish> a shell only runs the commands.  Why not just secure the commands themselves?
Oct 01 21:07:38 <grift> because a user doesnt want to be restricted
Oct 01 21:07:59 <Grommish> Oh dear.. I think it just clicked
Oct 01 21:08:00 <grift> when you log in with ssh you dont expect to be restricted
Oct 01 21:08:23 <Grommish> If it was encorporated into the builds, you couldn't update anything without a new push?
Oct 01 21:08:50 <Grommish> So an edge case would grind a user to a halt until "openwrt" fixed it?
Oct 01 21:08:51 <grift> the policy is loaded from the read only squashfs
Oct 01 21:08:56 <grift> yes
Oct 01 21:09:00 <Grommish> Balls
Oct 01 21:09:22 <Grommish> Can you re-write policy after it's loaded?
Oct 01 21:10:08 <grift> sure
Oct 01 21:10:15 <grift> and you can even reload it
Oct 01 21:10:27 <Grommish> are the policies in file form? can you just put the policy file into the sysupgrade?
Oct 01 21:11:05 <grift> the policy is a binary file that can be "loaded" with a command at runtime
Oct 01 21:11:09 <Grommish> then reapply the policies after the upgrade like now
Oct 01 21:11:26 <grift> so in theory you could transfer a updated policy file to the device and run load_policy
Oct 01 21:11:43 <Grommish> Ok.. that can be done in the 79_move_config
Oct 01 21:11:46 <grift> but that doesnt change the fact that when you boot, the policy is loaded from the squashfs
Oct 01 21:11:57 <Grommish> Ok
Oct 01 21:12:05 <grift> so when you boot , the file you copied to the device is not loaded
Oct 01 21:12:12 <Grommish> Wait
Oct 01 21:12:13 <grift> whats loaded is whats on the squashfs
Oct 01 21:12:33 <grift> because the policy is loaded before the / is setup
Oct 01 21:12:42 <grift> very early
Oct 01 21:13:08 <Grommish> https://github.com/openwrt/openwrt/blob/master/target/linux/octeon/base-files/lib/preinit/79_move_config
Oct 01 21:13:11 <grift> in other words practically you can't change the policy at runtime
Oct 01 21:13:22 <Grommish> That runs after the squashfs is loaded
Oct 01 21:13:39 <Grommish> and contains the sysupgrade file
Oct 01 21:13:45 <Grommish> at least for my device
Oct 01 21:13:48 <grift> yes but that would be fraggile and hacky
Oct 01 21:13:52 <Grommish> Why?
Oct 01 21:13:59 <Grommish> You just extract the sysupgrade file, as normal
Oct 01 21:14:06 <Grommish> and If they choose to save settings, it does that
Oct 01 21:14:11 <grift> because you would have to reload the policy a entra time
Oct 01 21:14:13 <Grommish> and runs the load_policy
Oct 01 21:14:22 <grift> plus that process needs to be allowed to load policy
Oct 01 21:14:28 <Grommish> That only runs during firstboot
Oct 01 21:14:42 <Grommish> to check for the sysupgrade file in ram
Oct 01 21:14:50 <Grommish> or rather, it checks each boot
Oct 01 21:14:59 <grift> if it only runs on first boot then it still doesnt solve much
Oct 01 21:15:29 <grift> anyhow its probably just not a route one wants to go in
Oct 01 21:15:41 <grift> it sets a precendent as well
Oct 01 21:16:03 <grift> the policy should just be make robust enough so that it just works
Oct 01 21:16:17 <grift> and it should be optional opt/in
Oct 01 21:16:47 <grift> and also it should be easy for people to create a ImageBuilder image with their own policy
Oct 01 21:17:13 <grift> but i dont think trying to make policy tunable at runtime is productive or realistic
Oct 01 21:20:05 <grift> i could be wrong though, would love for someone to prove me wrong
Oct 01 21:20:08 <Grommish> Then I'd target the core packages and processes that you know won't change and leave the rest to the wind for people to secure themselves if they think they need it
Oct 01 21:20:19 <grift> thats what i do
Oct 01 21:20:21 <Grommish> I imagine you'd remove opkg, for example, from your builds
Oct 01 21:20:38 <grift> no opkg is there its just not targeted
Oct 01 21:20:55 <grift> in a secure environment theres always a trust factor
Oct 01 21:21:04 <grift> and a package manager is to be trusted
Oct 01 21:21:16 <grift> we rely on other security measures for that
Oct 01 21:21:22 <Grommish> Right.. So, it's just a matter of getting a list of those packages that are in the core?
Oct 01 21:21:37 <Grommish> and getting them moved to a selinux version?
Oct 01 21:21:47 <grift> yes thats the idea
Oct 01 21:22:09 <grift> we just pick the common processes then look which one of them can be contained and target those
Oct 01 21:22:24 <grift> because we enforce integrity
Oct 01 21:22:35 <grift> and so that means enforcing least privilege
Oct 01 21:22:44 <Grommish> Gotcha..
Oct 01 21:22:44 <grift> a package manager basically needs full access
Oct 01 21:23:30 <grift> so yes selinux is all about comprosing its not a panacea
Oct 01 21:23:40 <grift> its a tool in the toolbox
Oct 01 21:23:42 <Grommish> That's security in itself
Oct 01 21:23:55 <Grommish> It won't ever cure and it has to be tightrope-walked for sure
Oct 01 21:24:03 <grift> yes
Oct 01 21:24:10 <grift> and thats the art of it
Oct 01 21:24:10 <Grommish> But, something is better than nothing for everyone
Oct 01 21:24:18 <grift> to find that elsive balance
Oct 01 21:24:18 <Grommish> and those that can and want more, can
Oct 01 21:24:47 <Grommish> You can save those policy changes over flashes.. i can help with that if nothing else
Oct 01 21:25:33 <Grommish> I can test brick my device in the name of selinux
Oct 01 21:25:52 <grift> nice i would appreciate help
Oct 01 21:26:04 <grift> but were not really there just yet
Oct 01 21:26:19 <grift> theres some labeling issue that probably should be resolved first
Oct 01 21:26:41 <Grommish> Ok..  Just let me know if there is something I can help test
Oct 01 21:26:52 <Grommish> I can always use a break from rust
Oct 01 21:27:01 <grift> but yes the policy needs testing, scrutinizing
Oct 01 21:27:16 <grift> ie people trying stuff see if it breaks
Oct 01 21:28:22 <grift> we should probably write up instructions on how to build an image with selinux and the basic policy and how to test it and provide feedback
Oct 01 21:28:54 <grift> but first we need to ensure that labeling is properly done because selinux relies on everything having a label
Oct 01 21:29:07 <grift> and theres some work ongoing there
Oct 01 21:29:19 <Grommish> Gotcha.. yeah, last test I did the labels were all missing
Oct 01 21:29:43 <grift> o yes that was you right? suricata?
Oct 01 21:29:46 <grift> execmem?
Oct 01 21:29:51 <Grommish> yeah
Oct 01 21:29:58 <grift> right that was nice of you
Oct 01 21:30:04 <grift> yea thats what we need
Oct 01 21:30:19 <grift> ill keep you posted, theres progress
Oct 01 21:30:42 <Grommish> thanks :) I'm not sure if I'll ever use selinux.. but I'm always willing to try and break something
Oct 01 21:31:05 <grift> yes thats fine
Oct 01 21:31:19 <grift> heck you might already be using selinux and not know it
Oct 01 21:31:33 <grift> have an android phone?
Oct 01 21:31:45 <grift> if so chances are that youre running selinux on it
Oct 01 21:32:04 <Grommish> Yeah, I'm sure it is on there.. prob on my ubuntu install as well
Oct 01 21:32:18 <grift> naw not ubuntu
Oct 01 21:33:52 <grift> but yes in theory if android can do it then why not openwrt (but i dont suggest the two are comparable though)
Oct 01 21:34:38 <Grommish> Any idea how they setup their labels?
Oct 01 21:35:05 <grift> yes some
Oct 01 21:35:24 <grift> in some way's identical to how openwrt does it
Oct 01 21:36:32 <grift> but sure we might be able to borrow some ideas from them to improve later
Oct 01 21:36:43 <grift> for now its not yet applicable
Oct 01 21:36:56 <Grommish> Yeah, still early in the process
Oct 01 21:37:03 <grift> were still in the infant stage where we just need to get the basics right
Oct 01 21:37:55 <grift> going to sleep , nice talking, gnite
Oct 01 21:38:16 <Grommish> Cya.. take care
Oct 01 23:05:56 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
Oct 01 23:49:31 <rr123> https://lwn.net/Articles/832876/  OpenWrt and SELinux
Oct 02 01:57:50 <anhnqt> hello everyone
Oct 02 01:58:38 <anhnqt> I cloned the newest openwrt source
Oct 02 01:59:03 <anhnqt> But can not see the target system for Atheros AR9xx
Oct 02 01:59:53 <anhnqt> Do you know why I cant see? Or the newest openwrt source is not support it?
**** ENDING LOGGING AT Fri Oct 02 02:59:57 2020