<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 _2_7  
28 29 30 31
00:15 Mr_H joined
01:11 czart__ joined
01:54 s33se_ joined
02:48 <Shiz> ncopa: just packaged the whole shebang related to gpg-remailer :P
02:49 <Shiz> silly people and their custom build systems...
03:02 <Shiz> https://github.com/alpinelinux/aports/pull/1355
03:02 <Shiz> :)
03:46 <Shiz> don't merge that yet btw, i may wanna add an initscript to it
05:22 BitL0G1c joined
05:24 Emperor_Earth joined
06:25 poptart joined
10:03 LouisA joined
10:37 consus joined
10:43 cyteen joined
11:10 <Shiz> jirutka ever diligent :P
11:11 <jirutka> :)
11:16 <jirutka> Shiz: build failed
11:16 <Shiz> yeah just saw it
11:16 <Shiz> working on it :)
11:18 <Shiz> running new build
11:56 D630 joined
12:14 <jirutka> Shiz: I’m crying… https://internals.rust-lang.org/t/pre-rfc-generalized-return-escape-continue-from-scopes/5173
12:15 <Shiz> is this goto with a fancier syntax
12:15 <jirutka> yes
12:15 <jirutka> and look at this https://github.com/Ericson2314/rust-rfcs/blob/goto/text/0000-goto.md
12:16 <jirutka> I hope that this will be never accepted
12:39 <Shiz> jirutka: how does gpg-remailerl ook now?
12:41 <jirutka> Shiz: look ok, just pls don’t prefix local variables with underscore; we use underscore prefix for global non-standard (i.e. not defined by abuild) variables
12:42 <Shiz> whoops
12:42 <Shiz> yeah i goofed a bit
12:42 <Shiz> i knew that, just didn't think :P
12:42 <Shiz> i'll rebase it
12:42 <jirutka> I added S-WIP b/c you’ve mentioned here that you’ll add runscript
12:43 <Shiz> yeah turns out there is no runscript anyway lol
12:43 <Shiz> i'm considerig adding a post-install hook to add a user for gpg-remailer but im not sure if thats necessary
12:44 <Shiz> it is intended to be ran as its own user, but otoh maybe its best left to the user to decide?
12:44 <jirutka> it doesn’t matter if upstream provides some runscript or not ;)
12:45 <jirutka> but if it’s typical to run the app as a daemon
12:45 <Shiz> no i mean, it's not meant to be ran as daemon anyway
12:45 <Shiz> :P
12:45 <jirutka> but how are you gonna deploy it?
12:45 <Shiz> it's meant to be invoked by your MTA
12:45 <jirutka> aha
12:46 <jirutka> okay, then runscript is indeed not needed
12:46 <Shiz> https://txt.shiz.me/MDk2NjE3Mj
12:46 <Shiz> like this :)
12:46 <Shiz> at least, that's my non-tested config
12:46 gromero joined
12:48 <jirutka> this can be simplified https://dpaste.de/NVzq/raw
12:48 <Shiz> oh, nice
12:48 <Shiz> the smtpd.conf manual seemed to imply it needed to be separate
12:48 <jirutka> also I don’t think that it’s necessary nor good to run it on a separate domain ;)
12:48 <Shiz> actually, it is
12:49 <jirutka> I know, the manual is not accurate about this
12:49 <Shiz> because else we need to hook deeply into alpine's existing infrastructure
12:49 <Shiz> and the gpg-remailer would need to run on the same node as the main MTA
12:49 <jirutka> I’ve seen this style in some examples and so tried it and it works, at least on 5.9, I haven’t tried 6.x yet
12:49 <Shiz> while with this
12:49 <Shiz> the main MTA can simply be configured to relay security@alpinelinux.org to security@security.alpinelinux.org
12:49 <Shiz> which runs isolated :)
12:50 <jirutka> not necessarily, you can relay security@alpinelinux.org from the main MTA to your
12:50 <jirutka> yours
12:50 <jirutka> aha, yeah XD
12:50 <Shiz> yes thats what i'm doing :P
12:50 <jirutka> but does it need TLS cert then?
12:51 <jirutka> and will it even work? I guess that it will run on a private IP?
12:51 <Shiz> it doesn't really need to
12:51 <Shiz> the private IP, that is
12:51 <Shiz> it can just run with the smtpd port publically-facing
12:51 <Shiz> there's no need for network isolation there :P
12:51 <jirutka> so I’m gonna merge PR#1355, okay?
12:51 <algitbot> Bug #1355: [v2.3] Multiple vulnerabilities in icedtea-web &lt; [1.1.6|1.2.1] may allow remote code execution - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/1355
12:51 <Shiz> jirutka: before you do, any opinions on the creating a user thing?
12:51 <jirutka> algitbot: be quiet, this is not useful here :P
12:52 <jirutka> Shiz: since there’s no runscript, I don’t think you should create a user in abuild
12:52 <Shiz> yeah makes sense
12:52 <Shiz> fine by me then \o/
12:52 <algitbot> \o/
13:19 LouisA joined
13:46 cyteen joined
14:38 <ncopa> seems like iputils' ping is broken on build-edge-s390x
14:38 <ncopa> but i have fixed busybox ping
14:38 <ncopa> kernel need ping_group_range
14:38 <Shiz> :)
14:38 <ncopa> and its ubuntu kernel
14:38 <ncopa> i still wonder why iputils ping is broke
14:39 <ncopa> build-edge-s390x:~$ ping -c1 127.0.0.1
14:39 <ncopa> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
14:39 <ncopa> ping: sendmsg: Invalid argument
14:41 <ncopa> sendmsg(3, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("8.8.8.8")}, msg_namelen=16, msg_iov=[{iov_base="\10\0J\373\342\323\0\7\0\0\0\0Y\r\3406\0\0\0\0\0\3\322\17\20\21\22\23\24\25\26\27"..., iov_len=64}], msg_iovlen=1, msg_control=[{cmsg_len=0, cmsg_level=0x8 /* SOL_??? */, cmsg_type=0}, 0x3ffdc5fd7e0], msg_controllen=28, ms
14:41 <ncopa> g_flags=0}, 0) = -1 EINVAL (Invalid argument)
14:51 eleksir joined
14:57 <Shiz> maybe the cmsg_level arg?
15:01 <Shiz> SOL_* for 0x8 doesn't seem defined
15:01 <Shiz> that i can see
15:02 <Shiz> ncopa: what version of iputils is this?
15:02 <ncopa> old
15:02 <Shiz> :P
15:02 t0mmy joined
15:02 <Shiz> btw the remailer thing is mostly set up
15:02 <Shiz> am just testing it now
15:02 <ncopa> nice
15:02 <ncopa> https://git.alpinelinux.org/cgit/aports/tree/main/iputils
15:03 <Shiz> that's pretty old yeah
15:03 <ncopa> https://git.alpinelinux.org/cgit/aports/tree/main/iputils/net-misc_iputils_files_iputils-20121221-fix-init-elemnt.patch
15:04 <Shiz> the value of cmsg is the mportant one
15:04 <Shiz> lemme check
15:05 <ncopa> maybe i should try upgrade it
15:05 <Shiz> the new version on github doesnt use the cmsg stuff
15:05 <Shiz> so maybe :)
15:05 <ncopa> new version is refactored
15:05 <ncopa> and i think it supports ping sockets
15:06 <ncopa> its possible the cmsg struct is not properly initialized
15:06 <Shiz> yeah it looks like it
15:06 <Shiz> see the struct on top of ping.c
15:12 <ncopa> looks like there is a "new" version of the implementation we use
15:12 <ncopa> https://wiki.linuxfoundation.org/networking/iputils
15:12 <ncopa> there is a 2015 version
15:12 <ncopa> but i wonder if we should just switch to the github.com/iputils/iputils version
15:13 <ncopa> or we just fix the one we have
15:13 <ncopa> yes i think you are right
15:14 <ncopa> the initialization is bad
15:18 eleksir joined
15:19 <ncopa> Shiz you are very correct. fixing it make it work
15:19 <ncopa> http://tpaste.us/Be0o
15:23 minimalism joined
15:24 eleksir joined
15:25 <Shiz> :)
15:27 <Shiz> finding hidden gpg-remailer dependencies
15:36 tmh1999 joined
15:39 mmlb joined
16:27 <Shiz> does adding dependencies to a package warrant a pkgrel bump?
16:27 <Shiz> not related to the build process, just adding missing stuff to depends=
16:40 <clandmeter> Yes
16:41 <clandmeter> Else it doesn't get build
16:41 <Shiz> gotcha
17:02 __0xAX joined
17:07 hiro joined
17:08 <hiro> why do we even have that debian style, but not, /etc/network stuff?
17:08 <hiro> is there a history to this that i can read about?
17:09 <Shiz> it's what busybox ifup/ifdown supports
17:11 <jirutka> hiro: we have /etc/network stuff, or what exactly do you mean?
17:11 <Shiz> they mean /etc/network/interfaces
17:11 <Shiz> i presume
17:11 <Shiz> why we use it
17:13 <hiro> correct, why do we have it?
17:13 <Shiz> Shiz │ it's what busybox ifup/ifdown supports
17:13 <Shiz> that's why :P
17:13 <jirutka> ncopa: yeah, IMO we should upgrade to iputils/iputils; about almost a year ago author of this fork caught me at some conference and recommended to upgrade to this version, it does support musl without patches and some other goodies
17:13 <hiro> all it seems to result in is users trying to apply their debian stackexchange answers to perceived problems
17:13 <jirutka> we have /etc/network/interfaces…
17:14 <Shiz> yes that is the point
17:14 <jirutka> maybe this file is not here by default
17:14 <Shiz> hiro seems to be of the opinion that we shouldn't
17:14 <Shiz> :P
17:14 <hiro> yes.
17:14 <Shiz> we have it because busybox supports it and it's thus the easiest way of supporting network setup
17:14 <jirutka> I agree, I don’t like this debian-style setup as well
17:14 <hiro> i know the manual way, the debian way, the openwrt way
17:15 <Shiz> in fact all the networking initscript does is for if in $ifaces ; do ifup $if ; done
17:15 <jirutka> but what alternatives we have? I was happy with netifrc on Gentoo, but its implementation is very hackish (very complex shell scripts)
17:15 <Shiz> with some stuff around it
17:15 <hiro> the openwrt being the most magic and powerful of the automatic ones...
17:15 <Shiz> i don't like magic
17:15 <hiro> and openwrt still doesn't do what i want, so i end up writing my own scripts instead
17:15 <Shiz> doesn't the openwrt stuff also deeply integrate with its ubus stuff
17:15 <jirutka> btw not sure how many ppl know about it, you can create symlinks for each interface, e.g. net.eth0 → networking, net.eth1 → networking, … and start them separately
17:16 <hiro> i have a few short awk scripts that parse ip monitor, wpa_supplicant, tunnel program and ping stats, and call some iproute2 magic with ip rule and in one case even with network namespaces.
17:16 <hiro> all this shit is really easy to do
17:17 <hiro> but if there's too much automagic stuff, users get discouraged to try on their own.
17:17 <jirutka> I know how to setup basically anything, including bodings and ppoe using netifrc, I have no idea even how to force dhcp client to not mess with default gateways in routing table, when I have multiple interfaces with dhcp…
17:17 <hiro> 19:15 Shiz doesn't the openwrt stuff also deeply integrate with its ubus stuff
17:17 <jirutka> (how to force… using that debian config)
17:17 <hiro> yes, ubus is a problem imo.
17:17 <Shiz> lol we're not going to force everyone to do their network config manually
17:17 <jirutka> afk
17:18 <Shiz> hmm
17:18 pickfire joined
17:20 <hiro> ok
17:35 <Shiz> jirutka: could you look at PR 1356 when you return? it's blocking my work on gpg-remailer :)
18:01 <jirutka> hiro: could you please share your network scripts? I’d like to see them for inspiration
18:02 <Shiz> jirutka: PR updated :)
18:02 <Shiz> and the libressl PR LGTM, but i'm going to try to repro it locally first
18:02 <Shiz> the issue they are having
18:09 <jirutka> Shiz: why have you declared replaces="mailx"?
18:09 <Shiz> because they both provide the same binary
18:09 <Shiz> /usr/bin/mail
18:09 <Shiz> i looked at gnupg1 and gnupg packages to see how to deal that
18:09 <jirutka> Shiz: then they should be in conflict imo
18:09 <Shiz> which did that
18:09 <jirutka> depends="!mailx"
18:09 <Shiz> well, gnupg1 did replaces= and provides= for gnupg
18:09 <Shiz> that's where i took my inspiration from :P
18:10 <jirutka> well, gnupg1 is a replacement for gnupg; is mailutils really a replacement for mailx?
18:10 <Shiz> mailx only has /usr/bin/mail, mailutils's /usr/bin/mail is a superset of mailx's
18:10 <Shiz> so, in a way
18:10 <jirutka> aha, okay
18:12 <jirutka> but it definitely should not `provides="mailx-$pkgver-r$pkgrel"`,
18:12 <jirutka> hm, I’m not 100% sure in this case tbh
18:13 <Shiz> me neither :P
18:15 <jirutka> okay, I’ll remove provides, merge it, so you can continue with work, and ask someone before moving to community :)
18:15 <Shiz> :)
18:15 <Shiz> maybe fabled or ncopa knows better
18:15 <jirutka> yeah
18:16 <jirutka> btw it’s replaces, not replace ;)
18:16 <* Shiz> shoots himself
18:18 <jirutka> hey, not needed to shoot, it’s not a big deal ;)
18:18 <Shiz> :P
18:21 <jirutka> hm, GH has some trouble with webhooks apparently
18:22 <jirutka> afk
18:23 <Shiz> :)
19:11 <Shiz> wee, gpg-remailer sends mails
19:58 <Shiz> the remailer/re-encrypter works :)
20:17 student0 joined
20:18 <student0> So you're the team that's keeping the ol' GRSEC patch alive! What's the new name gonna be?
20:19 <Shiz> are we?
20:20 <student0> last I heard. On Arch, Gentoo, even a GRSecurity rep pointed me this way. And when I get here, there's all these notices about GRSEC kernels all over the place!
20:21 <student0> Wait, Shiz, you did hear about this? https://grsecurity.net/passing_the_baton_faq.php
20:22 <Shiz> i think most people involved in hardening did, yea
20:22 <Shiz> only thing i can tell you is that we'll be maintaining 4.9.x as part of our 3.6 release cycle
20:22 <Shiz> that package is just called linux-hardened
20:23 <Shiz> there are no concrete plans beyond that, but i somehow doubt they involve grsec
20:23 <student0> Yeah. I'm from Gentoo and Arch. Haven't had the chance to contribute much.
20:24 <_ikke_> They renamed the grsec flavored kernel to hardened
20:24 <student0> But I'm not interested in letting that linux-hardened package go out of date after your 3.6 release cycle. That technology just has too much protection that I haven't found anywhere else.
20:24 <_ikke_> right
20:26 <student0> I'm down to help refactor the patch to keep up with newer kernels. But since the patch itself is a text file that's ~1.6x the collected works of Shakespeare (in .txt form), I'm not trying to do it alone.,
20:27 <student0> Am I in the right irc chat?
20:27 <_ikke_> yes
20:28 <Shiz> i've already been splitting up the grsec patch myself in fact
20:28 <Shiz> however, just splitting it up is not enough to be actually able to maintain it
20:28 <student0> From my username, you can guess that I have a student license for CLion.
20:28 <_ikke_> the IJ IDE for C?
20:29 <student0> the one that's considered the best in the industry for practically automating refactoring code.
20:30 <Shiz> the C IDE that doesn't support make?
20:30 <student0> The company that releases it is Jetbrains.
20:30 <Shiz> lol
20:30 <student0> Uhm, I dunno what you heard, but I don't use it without Make.
20:31 <Shiz> last i heard it only did cmake
20:31 <Shiz> anyway, like i said
20:31 <_ikke_> kaniini did try something with pax, but he got frustrated
20:31 <Shiz> i've been splitting up the patches to gain understanding about grsec, but i don't particularly have the hope of understanding it fully even in time when 3.6 is EOL
20:31 <Shiz> grsec and pax are tightly integrated into the kernel tree
20:31 <student0> how well do you know the kernel?
20:31 <Shiz> you kinda need deep understanding of how they work to maintain them across kernel versions
20:32 <Shiz> what areas of the kernel they affect, how they affect them, what new code may need new protection or annotations
20:32 <kaniini> and the grsec patches claim another victim
20:32 <Shiz> _ikke_: now you've done it :P
20:32 <kaniini> i wonder who shall be next
20:32 <Shiz> i've written kernel code before, so that counts for something i guess
20:34 <kaniini> writing kernel code isn't enough when the patch literally rewrites hundreds of thousands of variable declarations
20:34 <Shiz> yep
20:35 <Shiz> like i said, i don't particularly have hopes of understanding it even over the course of two years
20:35 <kaniini> that's the problem really. which variable declarations go to what feature.
20:36 <Shiz> » ./scripts/progress.sh
20:36 <Shiz> split hunks: 1515 (13.9%)
20:36 <Shiz> remaining hunks: 9376
20:36 <Shiz> :P
20:36 <Shiz> actually, that's been mostly okay so far
20:36 <Shiz> i've had more annoyance with manually splitting a single hunk into features that belong to different things
20:37 <student0> @kaniini - I've got some experience refactoring patches. My current setup includes greysky2's gcc native optimization patch (which I had to update myself), some wireless injection patches from kali, Grsec, zfs, one better support of my chipset's heat sensors - that one was fun to bring back up from the olden days of 3.18
20:37 <Shiz> well, security is kinda different than specific patches like zfs or kali
20:37 <Shiz> grsecurity*
20:37 <Shiz> because it touches EVERYTHING
20:38 <Shiz> and you can't just test it by 'it compiles/it boots, must work'
20:38 <Shiz> as in a lot of things with security, there's no feedback loop
20:38 <kaniini> that one is hard too yes
20:38 <student0> Good thing I'm in the middle of getting my OSCP then.
20:38 <Shiz> your feebdack loop is 'your box is pwed', not 'my kernel panics because it can't find the zfs rootfs'
20:38 <Shiz> and for us, that would extend to
20:38 <Shiz> 'every box running alpine is pwned'
20:38 <Shiz> :P
20:39 <Shiz> kaniini: speaking of invasive patches, how about that rap
20:39 <Shiz> lol
20:39 <student0> Yeah. That's nice. Lets write a script that'll automate a series of metasploit attacks.
20:40 <Shiz> i think my rap-x86-asm-fixes.patch is like 3-5k lines on its own
20:40 <kaniini> Shiz: i think W^X LSM and building the kernel with CFI is a pretty good start at a modern grsecurity replacement effort
20:41 <jirutka> Shiz: I have academic license for JetBrains as well, if you need ;)
20:41 <Shiz> i'm happy with my current editor, thanks
20:43 <Shiz> kaniini: did you see strcat's thing?
20:43 <student0> @Shiz, when a Penetration Tester that wants to maintain your patches wanders into your IRC, the conversation on testing no longer ends at "well, it compiles, but we don't know what else".
20:43 <student0> Ima go afk for a sec.
20:44 <kaniini> student0: with all due respect most "penetration testers" are just losers who fire up kalilinux and run some scripts. sooooooo
20:49 <student0> kaniini - I'm glad you understand how simple this whole thing can be on my end.
20:53 <student0> But, if you're interested in a budding professional who delivers reports from those scripts' results to a Fortune 500 company to audit their security, and I want the kernel patches that I've tested as providing the most resilience to stay open in the community?
20:54 <student0> The fact is, the GRSEC patch addresses a wide measure of vulnerabilities, but a finite (and constantly updating) set of vulnerabilities becomes the best test. You still need to know which scripts to run to test which holes are closed.
20:57 <student0> Yep, I'm a bit arrogant. But I'm down to help if you're interested in actually keeping that patchset maintained and *tested* properly.
20:59 <hiro> student0: last i looked grsec seemed completely useless, are there any news apart from that you upgraded your metasploit?
20:59 <student0> And I *do* know my way around the kernel better than most any loser that'll just throw scripts at shit to see what sticks.
21:01 <student0> hiro - Granted, this is from GRSec, but unless you've got a better option for the kinds of protections listed (USB port protection is trivially easy with USBkill) I'm reluctant to call GRSec useless: https://grsecurity.net/compare.php
21:01 <student0> And it stacks well with SELinux and/or apparmor.
21:02 <student0> I'm the idiot that likes to run all three at once, and maintain the configs of each regularly..
21:03 <hiro> i never said selinux is useful in any way
21:03 <student0> You either don't have to, or you're not qualified for this conversation.
21:04 <hiro> i am not qualified
21:04 <hiro> cause you are a professional
21:04 <hiro> and i'm just a kid who hates complex solutions to imaginary problems
21:04 <hiro> but ok, you probably also get more money than me, so i'll shut up
21:05 <student0> Remember that abstract and imaginary are very different things.
21:06 <student0> At the moment? I'm terribly underpaid for what I do. Living in a gov't heavy area, and being denied a clearance will do that. Hence why Im in school too. Hacking is fun, but you suck until you know how to build whatever it is you're supposed to take down/apart.
21:09 <student0> My favorite attack for when I need to destroy hardware is a sabotaged kernel module for reading temperature sensors.
21:12 <student0> I discovered the vulnerability by accident... but hey, once I got that motherboard back from the manufacturer, there was no reason not to weaponize my personal mistake.
21:14 <kaniini> blah blah blah
21:15 <student0> awww, you mean I don't get to join the club just by showing up, mentioning creds, and asking politely? lol
21:15 <kaniini> i'm interested in real solutions, not more grsec trolling
21:16 <student0> To my knowledge, grsec is a real solution. It just needs to be refactored to keep up with new kernel releases, and tested appropriately.
21:17 <student0> And industry certified Penetration Tester that refactors his own kernel patchset wanders in wanting to help with that, and you're not interested? Eh, after having to say "President Trump", I'm prepared for the disappointment.
21:20 <kaniini> grsec is a real solution, that comes with a giant stream of dumbass script kiddies telling us what to do and when to do it
21:20 <kaniini> so with all due respect a lot of us are pretty much over dealing with that
21:23 <student0> That's fair.
21:24 <kaniini> so yes absolutely in this case flashing creds just shows me ego, and therefore i can't say i'm terribly interested until i see tangible things backed by a community that isn't as fucked as the grsec one
21:25 <kaniini> we would obviously love to see grsec features reimplemented in a clean way, but we don't ever want to work with another spender
21:26 <kaniini> is the bottom line
21:26 <student0> I'm not familiar with spender.
21:26 blueness joined
21:27 <kaniini> he is not the most pleasant person in the world to work with
21:27 <student0> then, any suggestions on where I can find a pile of those script kiddies that want GRSEC, but will actually contribute?
21:27 <kaniini> lmao good luck
21:28 <kaniini> we don't actually want grsec itself
21:28 <kaniini> we want something that is actually viable to maintain
21:28 <kaniini> as has been demonstrated giant monolithic patches are not very maintainable now are they
21:28 <student0> if the patch weren't 1.5x the size of the collected works of Shakespeare in text, I'd just take a stab at doing it myself.
21:30 <kaniini> when spender first started going bonkers we started prototyping some aspects of grsec that we wanted
21:30 <kaniini> when time permits we will probably engage the KSPP guys to see if they can take those prototypes and flesh them out
21:31 <student0> cool. What parts are you considering trying to port?
21:33 <kaniini> MPROTECT (as LSM)
21:34 <student0> that's gonna be a huge project on its own, right there.
21:34 <kaniini> not really
21:34 <student0> oh?
21:34 <kaniini> i implemented an MPROTECT LSM 5 years ago
21:34 <kaniini> did quite well
21:34 <student0> nice!
21:35 <student0> Not touching PaX at all?
21:36 <kaniini> and people do underrate selinux
21:36 <kaniini> yes it's entirely awful to work with
21:36 <kaniini> but it shows how powerful LSMs are capable of being
21:37 <kaniini> what part of PaX? MPROTECT is part of PaX. sigh...
21:37 <kaniini> there's a lot of PaX that is largely increasingly support for legacy platforms
21:37 <kaniini> to emulate what is now hardware features
21:38 <kaniini> and no i'm not at all interested in any of that
21:38 <kaniini> every day the value for difficulty ratio drops further
21:39 <student0> One of the things that has had me sold on GRsec for so long was that it could be used with other LSMs, including SELinux. Can your MProtect module do that? What might be involved in maintaining that feature to it?
21:40 <kaniini> student0: UDEREF is worth implementing, but it looks like the KSPP guys are already working on it.
21:40 <kaniini> student0: MPROTECT does not need to stack with SELinux
21:41 <kaniini> student0: you would just implement W^X as an SELinux policy (the default policies already implement this, even)
21:41 <kaniini> student0: a lot of the stuff on the grsecurity website is bullshit, really
21:41 <kaniini> student0: keep in mind they want you to drop $500/mo/server on it, so they are going to mindfuck you a bit
21:43 tmh1999 joined
21:44 <student0> that's fair. Yet, it did seem like there was more going on past mprotect, and legacy-keeping. Was everything past that all smoke and mirrors?
21:46 <kaniini> uderef is really a good feature to take
21:46 <kaniini> a lot of PaX though is mitigation against hypothetical situations
21:47 <student0> eh... some of them have gotten less and less hypothetical...
21:47 <kaniini> so it is hard to assess value
21:47 <kaniini> because some have gotten less hypothetical, yes
21:47 <kaniini> either way, to succeed in getting security mitigations into a shape where they are maintainable, you have to do it incrementally.
21:48 <kaniini> by far, MPROTECT and UDEREF are the key PaX features. other features can likely be achieved in more sustainable ways, such as compiling the kernel with clang and it's Control Flow Integrity plugin (which is in some ways similar to RAP)
21:49 <student0> yeah, that USBkill script isn't hard to follow, on its own. But finding GRSec's implementation in that giant wall of patch... 0___0
21:50 <kaniini> but you get into really wacky shit like
21:50 <kaniini> "protection against a loaded kernel module overwriting an LSM's vtable"
21:51 <kaniini> which then some grsec "enthusiasts" incorrectly draw the conclusion that PaX will protect them from this
21:51 <kaniini> when the correct fix is "don't allow loading any new kernel modules to begin with"
21:51 <kaniini> which comes back to having appropriate system policy
21:53 <kaniini> student0: you may find https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project useful if you want to contribute to something right now
21:59 <student0> that nuclear option on loadable modules can be drastic outside of a server environment. Last I had played with it, GRSEC made overwriting SELinux's vtable more opaque when I attacked it on my own system. Maybe I had SELinux set up wrong, maybe they've fixed it since then. But to my knowledge, the patch did add protection in that particular case.
22:00 <kaniini> anyway
22:00 <kaniini> MPROTECT LSM, brute-force protection and a few other things i already have patches for
22:00 <kaniini> ;)
22:02 <student0> It wasn't the magic perfect protection that people make it out to be, but it'll stop a script kiddie and slow down just about anyone.
22:06 <student0> But I'm going to need some time looking around correlating what compile options reference what parts of the patch. I've always just trusted that patch implicitly, without really looking under the hood... I'm ashamed to admit that. But I know my way around the kernel.
22:07 <student0> Say, for sortof informally diagramming the patch's functionality in my head, is there anything that I wouldn't find by searching in the menuconfig section?
22:07 <student0> And yeah, the ol' Unix philosophy is absolutely superior.
22:19 <student0> kaniini - where would I find your patches posted publicly?
22:39 <kaniini> i do not presently have anything posted publicly.
22:39 <kaniini> that will come later, as time permits
22:39 <kaniini> as i need to rebase them anywasy
23:05 student joined
23:11 czart_ joined
23:25 student0 joined
23:35 cyteen joined
23:47 blueness joined
23:50 student0 joined
23:59 rfs613_ left