[HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/30/2010 05:01 PM, Tom Lane wrote:
> Paul Howarth <paul at city-fan.org> writes:
>> Paul Wouters <paul at xelerance.com> wrote:
>>> Can't selinux pickup things without a restorecon? And what is the
>>> problem another (root) process screwing over a pid or lock file?
>>> Can't SElinux lock that down from the /var/run level?
> 
>> /var/run is var_run_t in targeted policy, but hardly anything below
>> /var/run is - almost every subdir/file has its own context type.
> 
>> Just creating a file/directory within /var/run using the initscript will
>> inherit the var_run_t, which in most cases is not what's needed, hence
>> the need for restorecon.
> 
>> Having the daemon create the file/dir works better because there will
>> be a type transition defined in policy that results in the correct
>> context type being used.
> 
> That comment suggests you don't even understand the reason why those
> subdirectories exist.  It's this: the daemons do not, and should not,
> run with the root privileges needed to create things directly in
> /var/run.  The point of a subdirectory is to be owned by the
> lower-privilege account under which the particular daemon is running.
> If the subdir has to be remade at runtime, that has to be done by the
> root-privilege initscript, because /var/run is only writable by root.
> 
> I agree with Paul W that it's not obvious why selinux can't get this
> right for us, instead of requiring an extra easy-to-forget step in the
> initscripts.  But on the whole I'd rather this responsibility weren't
> getting dropped on the initscripts at all.  It works perfectly well to
> set up these dirs once via RPM --- why shouldn't we make the tmpfs
> creation process responsible for cloning the directory structure from
> disk?
> 
> 			regards, tom lane


SELinux can label a newly created directory in one of three ways.

1.

Either it adopts the label of the parent directory, in this case
var_run_t.  This is the most common what directories and files get
labeled, and has been stated is wrong.

2.
A second way a directory can be labeled is on transition rules.  We
write policy that says Process labeled a_t creating a directory in a
directory labeled b_t will get the label c_t.

Setroubleshoot for example has a rule that says

setroubleshootd_t creating directories in directories labeled var_run_t
will create the directory labeled setroubleshoot_var_run_t.

The problem is this only works for one combination, you can not have
another rule that says

a_t creating directories in b_t will create then as d_t.

3
The last way is to have the application have SELinux intelligence built
in.  systemd-tmpfiles has this, udev has this, passwd has this, most
apps do not, and we do not want most apps to do this.

So if you create a directory in the postinstall of an rpm, the directory
will be created as var_run_t (rule 1),  rpm has SELinux intelligence
built in, but since you did this in postinstall, rpm command does not
know you did it.  You will have to run restorecon.

If you create this directory in an /etc/init.d/foobar, this will be
running as initrc_t, and will create the directory as var_run_t, and you
will have to do restorecon.

If you do this with systemd-tmpfiles or do not ghost it in rpm spec
file, the correct thing will happen.

As far as remembering to run restorecon in init scripts or postinstalls.
 You have to run chcon and chown in the scripts often also, to make sure
the DAC LABEL is correct.  SELinux has been around for eight years now,
none of this is rocket science.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkz1e7UACgkQrlYvE4MpobPlcgCgqTtiYAi0wu5NaWzFmIpRUmyP
at4AoMfD6T4OLwafvZudVkUW8RZybSAK
=jpQc
-----END PGP SIGNATURE-----