<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/security/smack, branch v6.5.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>smack: Record transmuting in smk_transmuted</title>
<updated>2023-05-11T17:05:39+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2023-05-08T17:02:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2c085f3a8f23c9b444e8b99d93c15d7ce870fc4e'/>
<id>2c085f3a8f23c9b444e8b99d93c15d7ce870fc4e</id>
<content type='text'>
smack_dentry_create_files_as() determines whether transmuting should occur
based on the label of the parent directory the new inode will be added to,
and not the label of the directory where it is created.

This helps for example to do transmuting on overlayfs, since the latter
first creates the inode in the working directory, and then moves it to the
correct destination.

However, despite smack_dentry_create_files_as() provides the correct label,
smack_inode_init_security() does not know from passed information whether
or not transmuting occurred. Without this information,
smack_inode_init_security() cannot set SMK_INODE_CHANGED in smk_flags,
which will result in the SMACK64TRANSMUTE xattr not being set in
smack_d_instantiate().

Thus, add the smk_transmuted field to the task_smack structure, and set it
in smack_dentry_create_files_as() to smk_task if transmuting occurred. If
smk_task is equal to smk_transmuted in smack_inode_init_security(), act as
if transmuting was successful but without taking the label from the parent
directory (the inode label was already set correctly from the current
credentials in smack_inode_alloc_security()).

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
smack_dentry_create_files_as() determines whether transmuting should occur
based on the label of the parent directory the new inode will be added to,
and not the label of the directory where it is created.

This helps for example to do transmuting on overlayfs, since the latter
first creates the inode in the working directory, and then moves it to the
correct destination.

However, despite smack_dentry_create_files_as() provides the correct label,
smack_inode_init_security() does not know from passed information whether
or not transmuting occurred. Without this information,
smack_inode_init_security() cannot set SMK_INODE_CHANGED in smk_flags,
which will result in the SMACK64TRANSMUTE xattr not being set in
smack_d_instantiate().

Thus, add the smk_transmuted field to the task_smack structure, and set it
in smack_dentry_create_files_as() to smk_task if transmuting occurred. If
smk_task is equal to smk_transmuted in smack_inode_init_security(), act as
if transmuting was successful but without taking the label from the parent
directory (the inode label was already set correctly from the current
credentials in smack_inode_alloc_security()).

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>smack: Retrieve transmuting information in smack_inode_getsecurity()</title>
<updated>2023-05-11T17:05:38+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2023-05-08T17:02:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3a3d8fce31a49363cc31880dce5e3b0617c9c38b'/>
<id>3a3d8fce31a49363cc31880dce5e3b0617c9c38b</id>
<content type='text'>
Enhance smack_inode_getsecurity() to retrieve the value for
SMACK64TRANSMUTE from the inode security blob, similarly to SMACK64.

This helps to display accurate values in the situation where the security
labels come from mount options and not from xattrs.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Enhance smack_inode_getsecurity() to retrieve the value for
SMACK64TRANSMUTE from the inode security blob, similarly to SMACK64.

This helps to display accurate values in the situation where the security
labels come from mount options and not from xattrs.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'Smack-for-6.4' of https://github.com/cschaufler/smack-next</title>
<updated>2023-04-24T18:37:24+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-04-24T18:37:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dc7e22a368c2a217d2d3338b3bd984fdd0301173'/>
<id>dc7e22a368c2a217d2d3338b3bd984fdd0301173</id>
<content type='text'>
Pull smack updates from Casey Schaufler:
 "There are two changes, one small and one more substantial:

   - Remove of an unnecessary cast

   - The mount option processing introduced with the mount rework makes
     copies of mount option values. There is no good reason to make
     copies of Smack labels, as they are maintained on a list and never
     removed.

     The code now uses pointers to entries on the list, reducing
     processing time and memory use"

* tag 'Smack-for-6.4' of https://github.com/cschaufler/smack-next:
  Smack: Improve mount process memory use
  smack_lsm: remove unnecessary type casting
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull smack updates from Casey Schaufler:
 "There are two changes, one small and one more substantial:

   - Remove of an unnecessary cast

   - The mount option processing introduced with the mount rework makes
     copies of mount option values. There is no good reason to make
     copies of Smack labels, as they are maintained on a list and never
     removed.

     The code now uses pointers to entries on the list, reducing
     processing time and memory use"

* tag 'Smack-for-6.4' of https://github.com/cschaufler/smack-next:
  Smack: Improve mount process memory use
  smack_lsm: remove unnecessary type casting
</pre>
</div>
</content>
</entry>
<entry>
<title>Smack: Improve mount process memory use</title>
<updated>2023-04-05T15:46:14+00:00</updated>
<author>
<name>Casey Schaufler</name>
<email>casey@schaufler-ca.com</email>
</author>
<published>2023-04-05T15:46:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=de93e515db306767549bb29a926f523ca2a601ab'/>
<id>de93e515db306767549bb29a926f523ca2a601ab</id>
<content type='text'>
The existing mount processing code in Smack makes many unnecessary
copies of Smack labels. Because Smack labels never go away once
imported it is safe to use pointers to them rather than copies.
Replace the use of copies of label names to pointers to the global
label list entries.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The existing mount processing code in Smack makes many unnecessary
copies of Smack labels. Because Smack labels never go away once
imported it is safe to use pointers to them rather than copies.
Replace the use of copies of label names to pointers to the global
label list entries.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selinux: remove the runtime disable functionality</title>
<updated>2023-03-20T16:34:23+00:00</updated>
<author>
<name>Paul Moore</name>
<email>paul@paul-moore.com</email>
</author>
<published>2023-03-17T16:43:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f22f9aaf6c3d92ebd5ad9e67acc03afebaaeb289'/>
<id>f22f9aaf6c3d92ebd5ad9e67acc03afebaaeb289</id>
<content type='text'>
After working with the larger SELinux-based distros for several
years, we're finally at a place where we can disable the SELinux
runtime disable functionality.  The existing kernel deprecation
notice explains the functionality and why we want to remove it:

  The selinuxfs "disable" node allows SELinux to be disabled at
  runtime prior to a policy being loaded into the kernel.  If
  disabled via this mechanism, SELinux will remain disabled until
  the system is rebooted.

  The preferred method of disabling SELinux is via the "selinux=0"
  boot parameter, but the selinuxfs "disable" node was created to
  make it easier for systems with primitive bootloaders that did not
  allow for easy modification of the kernel command line.
  Unfortunately, allowing for SELinux to be disabled at runtime makes
  it difficult to secure the kernel's LSM hooks using the
  "__ro_after_init" feature.

It is that last sentence, mentioning the '__ro_after_init' hardening,
which is the real motivation for this change, and if you look at the
diffstat you'll see that the impact of this patch reaches across all
the different LSMs, helping prevent tampering at the LSM hook level.

From a SELinux perspective, it is important to note that if you
continue to disable SELinux via "/etc/selinux/config" it may appear
that SELinux is disabled, but it is simply in an uninitialized state.
If you load a policy with `load_policy -i`, you will see SELinux
come alive just as if you had loaded the policy during early-boot.

It is also worth noting that the "/sys/fs/selinux/disable" file is
always writable now, regardless of the Kconfig settings, but writing
to the file has no effect on the system, other than to display an
error on the console if a non-zero/true value is written.

Finally, in the several years where we have been working on
deprecating this functionality, there has only been one instance of
someone mentioning any user visible breakage.  In this particular
case it was an individual's kernel test system, and the workaround
documented in the deprecation notice ("selinux=0" on the kernel
command line) resolved the issue without problem.

Acked-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After working with the larger SELinux-based distros for several
years, we're finally at a place where we can disable the SELinux
runtime disable functionality.  The existing kernel deprecation
notice explains the functionality and why we want to remove it:

  The selinuxfs "disable" node allows SELinux to be disabled at
  runtime prior to a policy being loaded into the kernel.  If
  disabled via this mechanism, SELinux will remain disabled until
  the system is rebooted.

  The preferred method of disabling SELinux is via the "selinux=0"
  boot parameter, but the selinuxfs "disable" node was created to
  make it easier for systems with primitive bootloaders that did not
  allow for easy modification of the kernel command line.
  Unfortunately, allowing for SELinux to be disabled at runtime makes
  it difficult to secure the kernel's LSM hooks using the
  "__ro_after_init" feature.

It is that last sentence, mentioning the '__ro_after_init' hardening,
which is the real motivation for this change, and if you look at the
diffstat you'll see that the impact of this patch reaches across all
the different LSMs, helping prevent tampering at the LSM hook level.

From a SELinux perspective, it is important to note that if you
continue to disable SELinux via "/etc/selinux/config" it may appear
that SELinux is disabled, but it is simply in an uninitialized state.
If you load a policy with `load_policy -i`, you will see SELinux
come alive just as if you had loaded the policy during early-boot.

It is also worth noting that the "/sys/fs/selinux/disable" file is
always writable now, regardless of the Kconfig settings, but writing
to the file has no effect on the system, other than to display an
error on the console if a non-zero/true value is written.

Finally, in the several years where we have been working on
deprecating this functionality, there has only been one instance of
someone mentioning any user visible breakage.  In this particular
case it was an individual's kernel test system, and the workaround
documented in the deprecation notice ("selinux=0" on the kernel
command line) resolved the issue without problem.

Acked-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>smack_lsm: remove unnecessary type casting</title>
<updated>2023-03-08T17:35:20+00:00</updated>
<author>
<name>XU pengfei</name>
<email>xupengfei@nfschina.com</email>
</author>
<published>2022-10-26T08:29:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=502a29b04d857c28aa36f8829a5c673b9b8864a6'/>
<id>502a29b04d857c28aa36f8829a5c673b9b8864a6</id>
<content type='text'>
Remove unnecessary type casting.
The type of inode variable is struct inode *, so no type casting required.

Signed-off-by: XU pengfei &lt;xupengfei@nfschina.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove unnecessary type casting.
The type of inode variable is struct inode *, so no type casting required.

Signed-off-by: XU pengfei &lt;xupengfei@nfschina.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'Smack-for-6.3' of https://github.com/cschaufler/smack-next</title>
<updated>2023-02-22T20:52:59+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-02-22T20:52:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=77bc1bb18463a7fa3742accaddf31845655edf66'/>
<id>77bc1bb18463a7fa3742accaddf31845655edf66</id>
<content type='text'>
Pull smack update from Casey Schaufler:
 "One fix for resetting CIPSO labeling"

* tag 'Smack-for-6.3' of https://github.com/cschaufler/smack-next:
  smackfs: Added check catlen
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull smack update from Casey Schaufler:
 "One fix for resetting CIPSO labeling"

* tag 'Smack-for-6.3' of https://github.com/cschaufler/smack-next:
  smackfs: Added check catlen
</pre>
</div>
</content>
</entry>
<entry>
<title>smackfs: Added check catlen</title>
<updated>2023-02-21T19:22:02+00:00</updated>
<author>
<name>Denis Arefev</name>
<email>arefev@swemel.ru</email>
</author>
<published>2023-01-24T10:50:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ccfd889acb06eab10b98deb4b5eef0ec74157ea0'/>
<id>ccfd889acb06eab10b98deb4b5eef0ec74157ea0</id>
<content type='text'>
  If the catlen is 0, the memory for the netlbl_lsm_catmap
  structure must be allocated anyway, otherwise the check of
  such rules is not completed correctly.

Signed-off-by: Denis Arefev &lt;arefev@swemel.ru&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
  If the catlen is 0, the memory for the netlbl_lsm_catmap
  structure must be allocated anyway, otherwise the check of
  such rules is not completed correctly.

Signed-off-by: Denis Arefev &lt;arefev@swemel.ru&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: port acl to mnt_idmap</title>
<updated>2023-01-19T08:24:28+00:00</updated>
<author>
<name>Christian Brauner</name>
<email>brauner@kernel.org</email>
</author>
<published>2023-01-13T11:49:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=700b7940526d31117fd20b7ed31156df134fbe7f'/>
<id>700b7940526d31117fd20b7ed31156df134fbe7f</id>
<content type='text'>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: port xattr to mnt_idmap</title>
<updated>2023-01-19T08:24:28+00:00</updated>
<author>
<name>Christian Brauner</name>
<email>brauner@kernel.org</email>
</author>
<published>2023-01-13T11:49:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=39f60c1ccee72caa0104145b5dbf5d37cce1ea39'/>
<id>39f60c1ccee72caa0104145b5dbf5d37cce1ea39</id>
<content type='text'>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
