On Fri, 2010-02-26 at 15:52 -0500, Daniel J Walsh wrote:
> On 02/26/2010 03:47 PM, Stephen Smalley wrote:
> > On Fri, 2010-02-26 at 15:25 -0500, Daniel J Walsh wrote:
> >
> >> On 02/26/2010 03:16 PM, Stephen Smalley wrote:
> >>
> >>> On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote:
> >>>
> >>>
> >>>> On 02/26/2010 09:36 AM, Stephen Smalley wrote:
> >>>>
> >>>>
> >>>>> On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 02/26/2010 09:10 AM, Stephen Smalley wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> What version of the kernel was this added in? I don't want to
> >>>>>>>>> completely break old kernels using new toolchains (CLIP backports
> >>>>>>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it
> >>>>>>>>> is there, otherwise fall back to the old list.
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> This message was distributed to subscribers of the selinux mailing list.
> >>>>>>>>> If you no longer wish to subscribe, send mail to
> >>>>>>>>> majordomo@xxxxxxxxxxxxx with
> >>>>>>>>> the words "unsubscribe selinux" without quotes as the message.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> The problem with this is we end up with a lot of cruft in the toolchain,
> >>>>>>>> that is continually out of data, and makes it hard to figure out what
> >>>>>>>> the script is doing. We have older versions of the tool chain for those
> >>>>>>>> platforms, shouldn't we have sort of the latest toolchain.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> If we do that, we ought to make a major bump in the version numbers,
> >>>>>>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release
> >>>>>>> announcement clearly marks it as not backward compatible.
> >>>>>>>
> >>>>>>> With regard to fixfiles simplification though, can't we eliminate the
> >>>>>>> need to define or use FILESYSTEMS* altogether in the script by switching
> >>>>>>> all uses of setfiles to restorecon -R /, since that will automatically
> >>>>>>> skip non-labeled filesystems on kernels>= 2.6.30?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> It will still walk on read/only file systems.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> That should be fairly easy to fix in setfiles given that we are already
> >>>>> reading /proc/mounts - we can just add exclude on any ro mounts.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> How about this patch to remove ro mount points from setfiles/restorecon
> >>>>
> >>>>
> >>> Your logic depends on the option order - if "seclabel" appears first,
> >>> then you'll break out of the loop and never see the "ro". If we are ok
> >>> with that assumption (which happens to be true at present,
> >>> but /proc/mounts format is not guaranteed to remain stable), then it is
> >>> ok but then there is no reason to set found to 0 (already initialized to
> >>> 0). If we want to be robust against ordering changes, we'd need to drop
> >>> the break; from the seclabel case and keep scanning to check for any
> >>> subsequent "ro" options. Or you could just use strstr() on the entire
> >>> mount_info[3] and not worry about splitting it into tokens.
> >>>
> >>>
> >>>
> >> No I removed the break after finding seclabel, and set found to 0 if ro
> >> is found.
> >>
> >> So it will either search the entire structure for seclabel or break out
> >> with ro.
> >>
> >>
> >> + if (strcmp(item, "ro") == 0) {
> >> + found = 0;
> >> + break;
> >> + }
> >> if (strcmp(item, "seclabel") == 0) {
> >> found = 1;
> >> - break;
> >> }
> >>
> >>
> > Actually, given your other comment, I guess we can't do it this way, as
> > if they have e.g. read-only root with writable mounts underneath, we'll
> > never reach them.
> >
> >
> We have that problem with or without this patch. Since no seclabel is
> the same problem.
It isn't quite the same though. If someone were using SELinux, then I'd
expect their root filesystem to support labeling (otherwise init and
friends won't transition). But they might very well go with a read-only
root after installation.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
