[Dev] Smack aware softwares

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Thu Dec 12 23:52:49 GMT 2013

On Thu, 12 Dec 2013 16:29:29 +0000 "Schaufler, Casey"
<casey.schaufler at intel.com> said:

> > -----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
> > 
> > Hi,
> > 
> > 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.

just to not, turning off the atomic rename saving mechanism in vi (mind you
every cmdline text editor i know of does this - vi, emacs and jed too), is
unsafe. it can ultimately lead to file corruption. the write-to-tmpfile and
rename on top is a mechanism to ensure you have either the full old file R
complete new file, but NEVER anything in between. the rename guarantees

> > 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.
> > Regards
> > José Bollo
> > 
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

Carsten Haitzler (The Rasterman) <tizen at rasterman.com>

More information about the Dev mailing list