[Toybox] What's setransd?

[enh]

On Wed, Aug 18, 2021 at 3:27 AM Rob Landley <rob at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210818/0f85863f/attachment.htm>