|
Replies:
2
-
Last Post:
Sep 6, 2006 10:28 AM
by: gfaden
|
|
|
Posts:
320
From:
US
Registered:
4/14/06
|
|
|
|
Relabeling large files without copying them
Posted:
Sep 4, 2006 3:55 PM
To: Communities » security » discuss
|
|
|
|
In [u]Trusted Extensions[/u] a file's label is derived from the labeled zone which owns the underlying file system. In order to change the label of a file it normally must be moved (via the [b]global[/b] zone) to another file system owned by the zone with the appropriate label. The actual move operation is done in a shell script [b]/etc/security/tsol/relabel[/b] which is executed in the global zone, and simply relies on the [b]mv[/b](1) command. The mv(1) command renames the file, if possible.
If the source and destination pathnames correspond to files on different underlying devices, this requires the contents be copied from one file system and removed from the other. If you are going to be relabeling large files you may want to avoid copying the files. This can be done in two ways:
If all your zones are built using a single [b]UFS[/b] directory, e.g. [b]/zone[/b], then the source and destination pathnames corresponding to different zones will actually be managed on the same device, and the [b]mv[/b](1) operation in the global zone can simply rename the file to relabel it.
However, if you are using [b]ZFS[/b] for your zones, then each zone will be in its own dataset, and will be treated as a separate device. One way to avoid copying large files when relabeling them is to store each large file in its own dataset. In [b]ZFS[/b], a dataset has an associated mountpoint, which implies a sensitivity label in [u]Trusted Extensions[/u]. Changing the mountpoint property of a [b]ZFS[/b] dataset is equivalent to relabeling all the files in the dataset.
Here is an example. Assume we have a zpool called [b]zone[/b] ,and datasets [b]zone/public[/b] and [b]zone/internal[/b] corresponding to the [b]public[/b] and [b]internal[/b] zones. These are mounted by convention, at [b]/zone/public[/b] and [b]/zone/internal.[/b] Now suppose you have a set of large image files in the [b]internal[/b] zone which may be declassified in the future and moved into the [b]public[/b] zone. You can create a dataset to hold each such file, and initially associate them with the [b]internal[/b] zone:
[b]# zfs create zone/image1[/b]
[b]# zfs set mountpoint=/zone/internal/root/var/image1 zone/image1[/b]
Within the [b]internal[/b] zone, the pathname will appear as /var/image1. Supposed a file map1 is stored in this directory, and that we want to eventually declassify it and move it to the public zone. This can be done by an appropriately privileged user using the command:
[b]# setlabel public /var/image1/map1[/b]
Assuming the user has sufficient privileges and authorizations (see [b]setflabel[/b](3) for details), the file will be copied into the[b] /var/image1[/b] directory in the public zone. However, if the file is large, it would be more efficient to remount it into the public zone. Since it is in its own dataset, it can be remounted and relabeled without affecting any other files. This can be done automatically by making a few changes to the existing shell script which does the relabeling.
|
|
|
Posts:
11
From:
Minneapolis, MN
Registered:
7/18/06
|
|
|
|
Re: Relabeling large files without copying them
Posted:
Sep 6, 2006 4:48 AM
in response to: gfaden
|
|
Along those lines, is it easily possible to set a specific process to run
at a specific label rather than having an entire zone running in support
of a single process? I see that any process running in a local zone also
appears as running in the global zone at a specific label (same process
ID). Is it possible to short-circuit that process and say that instead of
running an entire zone complete with services, CPU usage, and memory
allocation to simply run that process with a specific label?
I was thinking of something like when we allocate devices. We can allow a
device to be allocated to a specific zone using the device allocation
manager or, if it is always going to be assigned a specific label, we
simply allocate that device to that specific zone using zonecfg. No
matter what, that device will always have that specific label, because it
is always assigned to that zone (with its subsequent label).
However, in this case, we know that no matter when or how this process
gets invoked, it will always run at a specific label. Instead of booting
an entire zone to run this one process, we could run this one process from
the global zone and it will always run at that specific label. It would
save on memory and performance, and you could start that process
instantaneously instead of having to wait for the zone to initialize.
-- Mike
> In [u]Trusted Extensions[/u] a file's label is derived from the labeled
> zone which owns the underlying file system. In order to change the label
> of a file it normally must be moved (via the [b]global[/b] zone) to
> another file system owned by the zone with the appropriate label. The
> actual move operation is done in a shell script
> [b]/etc/security/tsol/relabel[/b] which is executed in the global zone,
> and simply relies on the [b]mv[/b](1) command. The mv(1) command renames
> the file, if possible.
>
> If the source and destination pathnames correspond to files on different
> underlying devices, this requires the contents be copied from one file
> system and removed from the other. If you are going to be relabeling
> large files you may want to avoid copying the files. This can be done in
> two ways:
>
> If all your zones are built using a single [b]UFS[/b] directory, e.g.
> [b]/zone[/b], then the source and destination pathnames corresponding to
> different zones will actually be managed on the same device, and the
> [b]mv[/b](1) operation in the global zone can simply rename the file to
> relabel it.
>
> However, if you are using [b]ZFS[/b] for your zones, then each zone will
> be in its own dataset, and will be treated as a separate device. One way
> to avoid copying large files when relabeling them is to store each large
> file in its own dataset. In [b]ZFS[/b], a dataset has an associated
> mountpoint, which implies a sensitivity label in [u]Trusted
> Extensions[/u]. Changing the mountpoint property of a [b]ZFS[/b] dataset
> is equivalent to relabeling all the files in the dataset.
>
> Here is an example. Assume we have a zpool called [b]zone[/b] ,and
> datasets [b]zone/public[/b] and [b]zone/internal[/b] corresponding to the
> [b]public[/b] and [b]internal[/b] zones. These are mounted by convention,
> at [b]/zone/public[/b] and [b]/zone/internal.[/b] Now suppose you have a
> set of large image files in the [b]internal[/b] zone which may be
> declassified in the future and moved into the [b]public[/b] zone. You can
> create a dataset to hold each such file, and initially associate them with
> the [b]internal[/b] zone:
>
> [b]# zfs create zone/image1[/b]
>
> [b]# zfs set mountpoint=/zone/internal/root/var/image1 zone/image1[/b]
>
> Within the [b]internal[/b] zone, the pathname will appear as /var/image1.
> Supposed a file map1 is stored in this directory, and that we want to
> eventually declassify it and move it to the public zone. This can be done
> by an appropriately privileged user using the command:
>
> [b]# setlabel public /var/image1/map1[/b]
>
> Assuming the user has sufficient privileges and authorizations (see
> [b]setflabel[/b](3) for details), the file will be copied into the[b]
> /var/image1[/b] directory in the public zone. However, if the file is
> large, it would be more efficient to remount it into the public zone.
> Since it is in its own dataset, it can be remounted and relabeled without
> affecting any other files. This can be done automatically by making a few
> changes to the existing shell script which does the relabeling.
>
>
> This message posted from
> opensolaris.org_______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris dot org
--
Michael Lewis -- Jackpine Technologies Corporation
1380 Corporate Center Curve, Suite 108, Eagan, MN 55121
(651)209-6042 -- mdl at JackpineTech dot com
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
Posts:
320
From:
US
Registered:
4/14/06
|
|
|
|
Re: Relabeling large files without copying them
Posted:
Sep 6, 2006 10:28 AM
in response to: mdlewis
|
|
Mike Lewis wrote:
> Along those lines, is it easily possible to set a specific process to run
> at a specific label rather than having an entire zone running in support
> of a single process? I see that any process running in a local zone also
> appears as running in the global zone at a specific label (same process
> ID). Is it possible to short-circuit that process and say that instead of
> running an entire zone complete with services, CPU usage, and memory
> allocation to simply run that process with a specific label?
>
No, the label of a process is derived from the zone's label. However,
file labeling only requires that zones are at least ready (not
completely booted). In the ready state the file systems specified in the
zone's zonecfg file and its dfstab file are mounted and shared. So the
scenario I described in this thread (relabeling files) does not require
that the zone corresponding to the new label is booted, just ready.
Even running zones can be fairly light weight. Now that the Secure by
Default project has integrated into Nevada, zones are started with far
fewer services and therefore start more quickly and consume fewer
resources. Most interesting processes depend on at least a few services,
so it is not generally practical to run a zone with just one process.
But you can get pretty close to this state by disabling unused services.
--Glenn
> I was thinking of something like when we allocate devices. We can allow a
> device to be allocated to a specific zone using the device allocation
> manager or, if it is always going to be assigned a specific label, we
> simply allocate that device to that specific zone using zonecfg. No
> matter what, that device will always have that specific label, because it
> is always assigned to that zone (with its subsequent label).
>
> However, in this case, we know that no matter when or how this process
> gets invoked, it will always run at a specific label. Instead of booting
> an entire zone to run this one process, we could run this one process from
> the global zone and it will always run at that specific label. It would
> save on memory and performance, and you could start that process
> instantaneously instead of having to wait for the zone to initialize.
>
> -- Mike
>
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
