[Toybox] Squinting at LSM support in cp.

Thu Jul 2 18:02:18 PDT 2015

Hi. My link was wrong.
You can access below probably, like a link "Tizen" at toybox main page.
https://git.tizen.org/cgit/external/tizen-coreutils.git/tree/packaging/coreutils-6.9-smack.patch?h=tizen_2.3

And share one more site :
http://schaufler-ca.com/description_from_the_linux_source_tree
This is smack project community, and Schaufler is the founder of this
project.
It includes "Applying Access Rules" section more. Is it helpful for you?

Actually, Above tizen-coreutils patch also wasn't made by tizen team with
considering TRANSMUTE flag I think.

2015-07-02 4:41 GMT+09:00 Rob Landley <rob at landley.net>:

> On 07/01/2015 12:17 AM, Hyejin Kim wrote:
> > There is a reference in tizen, repository called external/tizen-coreutils
> > It has a patch to cover smack feature into some commands.
> >
> >
> https://review.tizen.org/gerrit/gitweb?p=external/tizen-coreutils.git;a=blob;f=packaging/coreutils-6.9-smack.patch;h=1ac188e50938d51c4ac8f2ce605580ee1b8da2f0;hb=HEAD
> > (If you can't access this, plz register account or let me know)
>
> It popped up a login request and wouldn't let me access the page without
> a username/password, and there was no obvious link to account creation
> from the error page.
>
> If I need an account to view the source, it's not an open source project.
>
> > I guess it will be helpful that you understand their intention more.
> >
> > As Jose mentioned, there is one more xattr for directory, named
> > security.SMACK64TRANSMUTE (Now what we are using to save label is
> > security.SMACK64)
> > plz, refer to the explanation.
>
> Below, or at the link above?
>
> > What is __security.SMACK64TRANSMUTE__ ?
> > ==> Can only have the value "TRUE".
>
> So they've reinvented the sticky bit with a new meaning. And for some
> reason, it has a "64" in it. (Was there a SMACK32?)
>
> > If this attribute is present on a directory when an object is created in
> > the directory and the Smack rule (more below) that permitted the write
> > access to the directory includes the transmute ("t") mode
> > the object gets the label of the directory instead of the label of the
> > creating process. If the object being created is a directory the
> > SMACK64TRANSMUTE attribute is set as well.
>
> The first patch I was sent (Krzysztof Sasiak <k.sasiak at samsung.com> in
> the tizen pull request) didn't do that. It only copied xattrs on files,
> not on directories or dev nodes or fifos or symlinks... (Can symlinks
> have xattrs?)
>
symlink(or directory) can have its own label. it is tested by using chsmack
command (in the smack-util)
Further this is a part of setxattr's man page. context is based on inode.

<http://man7.org/linux/man-pages/man2/setxattr.2.html#DESCRIPTION>DESCRIPTION
        top
<http://man7.org/linux/man-pages/man2/setxattr.2.html#top_of_page>

       Extended attributes are *name*:*value* pairs associated with inodes
       (files, directories, symbolic links, etc.).  They are extensions to
       the normal attributes which are associated with all inodes in the
       system (i.e., the stat(2)
<http://man7.org/linux/man-pages/man2/stat.2.html> data).

*       setxattr*() sets the *value* of the extended attribute identified by
       *name* and associated with the given *path* in the filesystem.
The *size*
       argument specifies the size (in bytes) of *value*; a zero-length value
       is permitted.

       *lsetxattr*() is identical to *setxattr*(), except in the case of a
       symbolic link, where the extended attribute is set on the link
       itself, not the file that it refers to.

>
> Presumably this avoids the issue of confusing your own cp -r by creating
> directories that then alter their contents to not match the original.
> (At least using the "set creation context" mode of labeling objects to
> avoid leaving an exploitable race window between create and label.)
>
> It's also the wrong thing to do. (If I'm going to do this at all, I want
> to do it right.) We already _know_ there are labels that do something on
> a directory, we're discussing one right now, is --preserve=context _not_
> supposed to preserve them? (How about --preserve=xattr?)
>
> The other question is how far up the tree does this check go? Can you cp
> -r into a directory that already has SMACK64TRANSMUTE on it? (Even if it
> only goes one level deep, it can still screw up the top level...)
>
> > For this reason, I guess that a file can't have a bucket of labels. and
> > security.SMACK64 xattr is just one per a file or path.
>
> The second patch (from Jose, at
> http://lists.landley.net/pipermail/toybox-landley.net/2015-May/004184.html
> ) has this:
>
> +    flistxattr(fdin, list, listlen);
> +    for (name = list ; (name - list) < listlen ; name +=
> strlen(name)+1) {
> +      /* test if the xattribute have to be copied */
> +      if ((TT.preserve & p_xattr)
> +      || ((TT.preserve & p_mode) &&
> +              !
> strncmp(name,"system.posix_acl_",sizeof("system.posix_acl_")-1))
> +      || ((TT.preserve & p_context) &&
> +              !strncmp(name,"security.",sizeof("security.")-1)))
> +      {
> +        /* yes, try to copy it */
> +        if ((len = fgetxattr(fdin, name, 0, 0)) > 0 && (value =
> malloc(len))) {
> +          fgetxattr(fdin, name, value, len);
> +          err += !!fsetxattr(fdout, name, value, len, 0);
> +          free(value);
> +        } else err++;
> +      }
> +    }
>
> Note the two strncmp(), hardwiring in smack and selinux security label
> names without a config symbol. Those are operating on prefixes, which
> imply there could be multiple entries after them.
>
> I also very very vaguely remember enh or somebody mentioning that the
> selinux defaults can be something like a comma separated list of
> attributes, but really want to just pass through unmodified strings to
> let the existing infrastructure handle that if at all possible.
>
> The above snippet is from a cp_xattrs() function which is only called
> once, right after xsendfile(), and thus once again only operates on
> strings. (Which is inda broken in that it's handling both
> --preserve=xattrs and --preserve=context and the _first_ of those should
> definitely operate on everything.)
>
> If the definition is that --preserve=context only operates on files,
> then I can set the default creation context and reset it back to
> whatever it was right afterwards. (Unless the right thing to do is
> _clear_ it at the start because --preserve=context overrides creation
> context the same way -p overrides umask().)
>
> In theory I can have --preserve=xattr just copy xattrs for every node
> after creation in the loop, and --preserve=context set the creation
> context just on files after copying the contents, and that way if you
> specify both it may do it twice but at least for files it should both
> give you the right eventual result _and_ not have an obvious race where
> you can fiddle with a file's contents before the label shows up.
>
> (The really really annoying part is I feel like I'm putting more thought
> into this than the people who created it. I want somebody to tell _me_
> how to do this, without me being able to spot holes in the first 15
> seconds...)
>
> > Further, above link doesnt call flistxattr() like Jose did for cp
> command.
>
> Above link didn't give me a page.
>
> Sigh, lemme see what I can dig up. Google for tizen-coreutils gives me
> https://review.tizen.org/git/?p=external/tizen-coreutils.git;a=tree
> and "log" on that says the most recent commit was almost 3 years ago,
> but let's see if I click on a commit and then cut and paste your link's
> hash into that URL...
>
>
> https://review.tizen.org/git/?p=external/tizen-coreutils.git;a=commit;h=1ac188e50938
>
> Unknown commit object.
>
> Nope. No idea how to navigate this. There are a couple of tags newer,
> but not tree commits? (Am I misunderstanding branches here? A log on the
> most recent tag gives me two commits, and when I click the newest _is_ a
> more recent commit than a log on the tree but it has no parent...?)
>
> If I was just wandering past and examining the repository I just found
> with Google (first hit for "tizen coreutils", I'd think development
> ceased years ago. It might have been included verbatim in a couple new
> releases by some sort of distro-wide tagging, but it hasn't even had
> bugfixes applied since 2012.
>
> I'm guessing this is not actually the case, merely the public face you
> present to the open source community?
>
> > Thanks.
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150703/5d189e41/attachment-0004.htm>