On Wed, Aug 18, 2021 at 3:27 AM Rob Landley <r...@landley.net> wrote:
> I'm trying to implement tar --selinux and it really looks like > setfscreatecon() > and getfileconat() mostly boil down to simple things like "open a /proc > file and > read/write a blob of data", ala: > > int sefd = -1; > ... > if ((FLAG(selinux) && !(FLAG(t)|FLAG(O))) > && strstart(&pp, "RHT.security.selinux=")) > (it's just called security.selinux where i come from... see XATTR_NAME_SELINUX in <linux/xattr.h>.) > { > i = strlen(pp); > sefd = xopen("/proc/self/attr/fscreate", O_WRONLY|WARN_ONLY); > if (sefd == -1 || i!=write(sefd, pp, i)) > perror_msg("setfscreatecon %s", pp); > } > ... > if (sefd != -1) { > write(sefd, 0, 0); > close(sefd); > sefd = -1; > } > > > ...except that's the _raw versions of the function. The non-raw versions > do a > network transaction (via _iovec_???) with "setransd" and googling for that > one > of the first hits is https://selinuxproject.org/page/MLSStatements which > talks > about translating security context info to/from "human readable" format? > (fwiw, Android builds with -DDISABLE_SETRANS, but i don't know about other systems.) > I'm aware this was invented by Red Hat and is thus at LEAST as insane and > overengineered as systemd, but... do you know what that's all about and is > there > an easy way for me to NOT? (I dowanna try to do magic fallback config > things to > chop the --selinux help text out of the help text, I've changed my mind > about > that level of complexity/configurability being worth it and kind of want to > eliminate that plumbing. So it's going to always DOCUMENT --selinux but > can't > link to the library functions without the config symbol enabled, but if I > don't > actually NEED the library... > > Yeah, I _CAN_ add a lot more "#define setfscreatecon(...)" crap to stub > out the > functions when it's disabled, but I don't want to? "Reach out and talk to > the > kernel directly" looked almost sane for a moment as long as I didn't have > to > care what was IN the data blob. Which none of the other implementations > seems > to, but they're using the "cooked" functions which go through this daemon > I've > never heard of which doesn't appear to have anything like a man page... > yeah, i'm not sure why you're bothering with this? just let libselinux hide this cruft like you do for the rest of the selinux stuff? "not using libselinux" seems likely to upset the folks who _want_ selinux. even if it is, as you point out, pretty bad when you actually look at the implementation --- duplicating it just means now they have _two_ things that they have to audit. (similar to the libcrypto argument, though there there's FIPS that explicitly *mandates* not duplicating things, but i think the mentality is similar regardless.) more practically, there's a bunch of local Android configuration in our libselinux, and i'm guessing (from your claim that RedHat doesn't even use the same name for the attribute!) that's true of the various Linux distros too... so potentially you end up needing to carry all the local cruft for every user too. doesn't seem worth it? just #define no-op variants in portability.h and let selinux users rely on their local libselinux? > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net