On 07/16/2015 12:26 AM, James McMechan wrote: > For some odd reason the reply got routed to [email protected] not the toybox > list...
Heh, I replied to that asking you to repost here, and you'd already done it. :) >> Date: Tue, 14 Jul 2015 19:31:43 -0500 >> From: [email protected] >> To: [email protected] >> CC: [email protected] >> Subject: Re: [Toybox] Squinting at LSM support in cp. >> >> On 07/14/2015 03:24 PM, enh wrote: >>> On Fri, Jul 10, 2015 at 11:33 AM, Rob Landley <[email protected]> wrote: >>>> Alas I have _no_ idea how to explain that last part concisely in the >>>> help text. I'm also aware --no-preserve=context seems like it should >>>> strip security context and if people want to argue for that instead, I'm >>>> going to rant about how this entire mess is badly designed and there >>>> should already be some xattr version of chmod -R that does a regex >>>> search and replace on extended attribute key/value pairs, and that if >>>> such a tool doesn't already exist to be copied then this LSM stuff >>>> doesn't get used by non-bureaucrats, and cp probably isn't that tool >>>> although maybe it can share infrastructure with it, and then I'd ask >>>> somebody to explain to me what cp --attributes-only is for exactly? >>> >>> there's no chmod/chown equivalent in the literal sense, but >>> restorecon(8) is probably the closest. basically you don't trust >>> arbitrary operations, and you have a tool that applies the correct >>> labels based on its configuration. (so you have to get the >>> configuration right, but you can largely ignore arbitrary fs >>> modifications.) >>> > I seem to note a chsmack command If somebody wants to send me an implementation (or a link to a man page). I still don't have a proper smack test environment. (I have a snapshot of phone software running in an emulator, but no build environment for it.) >>> note also that most processes can't set a file's label, and not having >>> a label is fail-safe in the sense of "that gets you nothing". >> >> Ok, so labels never _restrict_ access to files, they just grant extra >> things to them? ("I could do X with this file/directory if it wasn't for >> the label on it" does not ever apply?) >> >> That would make the race conditions a lot less of an issue, yes. > > Yes it would make it simpler, alas I expect this is another choose two of > three > reliable, secure, simple. > > I seem to remember that yes you can restrict permissions via labels > e.g. the section that talks about "These rules are only consulted if > access would otherwise be permitted" would imply that it is only > checked when you already have permission from the system. > > So it looks like it can only disallow, I seem to remember there was a debate > about this when MAC went in that permissive actions should not be permitted > by the MAC only disallow... Except permissive actions are the ones that _don't_ have race conditions when copying a hierarchy. (Or at least less obvious ones.) > That we have at least two different security implementations that both seem > to assume you will never > do anything outside of their particular sandbox does not help, along with > attributes being used for > every different kind of metadata and all of them assuming that their use is > the only important one Tell me about it. I'm not the one who opened this can of worms. :) > I seem to remember ACLs are also implemented in xattrs so are alternate data > streams, so you have one > set of assumptions that the data is small zero terminated string that can be > read atomically and other > uses where it may be a named mulit-gigabyte binary blob. Of course. > As I recall XFS, NTFS, HFS+, Reiserfs4 all support unlimited size meta data > in the xattrs > the ext[234] series had I think something like a one block limitation which > could easily be hit and I don't know > about the other filesystems. Nothing supports "unlimited size" on finite block devices. :) Failure to write acl data can be because the disk filled up, so you always have to be prepared for it. In the case of cp --preserve I dunno what the right response is. Returning an error code from the top level process could mean "failed to create a symlink" not "an important file is missing its security label". > Thinking about it having separate parsers based on the name of each > xattr for each security mode to see if > it adds or removes permissions for !simple but reliable and secure > or just setting permissions to 700 copying over the contents and xattrs > and then changing to the correct permissions !reliable but simple and secure > or sticking the xattrs on after copying and setting the permissions !secure > but simple and reliable... The problem with setting to 700 and then labeling, can the label veto a chmod after the fact? (I dunno _what_ they can do.) I'm in the process of cutting a release, so all of this gets punted to next version. (Which should only be in a month or two, I'm trying to get my aboriginal linux test environment back in sync with the kernel releases, and each one of those should flush the toybox updates into a tested release.) > I would pick #2 since it looks like it should mostly work and when you have > weird exceptions it would be weird... > > On the history side I first ran into weirdness like this years ago ~1989? > with HP's CDF Context Dependant Files > see 5.9 Oddities and Dubious Ideas -> 5.9.2 Context-Dependent Files > http://docstore.mik.ua/orelly/networking/puis/ch05_09.htm I have yet to see anybody move beyond simple unix permissions in a way that doesn't collapse into unmanageable complexity, but people assure me it works for them. (I like containers because it mostly just tries to make conventional unix permissions _nest_, which only adds one new concept to the mix and it's similar to a concept networking already gave us years ago. There may be implementation problems with containers, but the design goals are a lot more obvious and easier to agree on.) > I get the feeling that the triangular wheel has been reinvented again... Many, many times. > Personally I have never liked the out of band attempts to fix the fact > you can't have user created groups or more than one group per file > I don't even configure my filesystems with xattr support unless I expect > to need it, which has not occurred in the last 30 years. Containers. They make sense. (The various _implementations_ are a bit funky, but that was true of unix in the 80's, too...) >> Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
