[Dev] Smack aware softwares
casey.schaufler at intel.com
Thu Dec 12 16:29:29 GMT 2013
> -----Original Message-----
> From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On
> Behalf Of José Bollo
> Sent: Thursday, December 12, 2013 7:05 AM
> To: dev at lists.tizen.org
> Subject: [Dev] Smack aware softwares
> Some colleagues and me have noted that editing a file with 'vi' may change
> its security.SMACK64 access label (if your are root for example).
This is because vi does not modify the file in place.
It creates a temporary copy (which gets the Smack label of the process)
and modifies that. When you're done it removes the old version and
renames the new with the old name.
> It comes from the 'vi' that isn't aware of Smack. A brief look into its sources
> allow to conclude that 'vi' is aware of SELINUX but not of Smack.
From a strict Mandatory Access Control standpoint the existing
Smack behavior is correct. If you are running with a Smack label
of Blanc and creating files they should all be labeled Blanc, regardless
of the source of their contents. Because vi provides the illusion of
modifying the file in place there is an argument for allowing it to
attempt to set the label to match that of the original file when
run with privilege.
> So it will be
> easy to just adapt the small SELINUX part of 'vi'
> to handle Smack.
Yes, you could. If that's turning off the backcopy option it should work fine.
> But it reaches the question of the autotools. Is there any
> macro for the autotools? I'm seeing some in coreutils.
No, work has not been applied there.
> Further, we looked at what are the tools that must carefully handle Smack.
> Many work have be done.
> - ls -Z shows the access property of files
> - id -Z prints the current context
> - mkdir -Z set created directories access
> - cp --preserve=all|xattr copies Smack properties
> - rsync -X preserve extended attributes
You missed ps -Z
We've made an effort to take advantage of the work that SELinux has done
on utilities, partly to keep the interfaces as common as possible and partly
because it reduces the development effort.
> We are also finding that 'tar' isn't aware of extended attribute. It isn't sure to
> preserve extended attribute in normal exchanges. But for backups, it is
> merely usefull.
Extended attribute support for tar has been an issue since (I am not kidding) 1987.
There are lots of ways to accomplish adding xattrs to the tar format, but none
has been deemed acceptable by the community.
> So on the short list of what have to be Smack aware, we have VI and TAR.
> * https://bugs.tizen.org/jira/browse/PTREL-542
> * https://bugs.tizen.org/jira/browse/PTREL-543
We will be happy to see patches for either or both. Changes to
vi are much more likely to be community acceptable than
changes to tar, but don't let that discourage you.
> José Bollo
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev