From: Casey Schaufler <casey@schaufler-ca.com>
To: Tang Peter <Peter_Towne@hotmail.com>
Cc: "linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"gaolong@yhkylin.cn" <gaolong@yhkylin.cn>,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: 回复: [RFC PATCH 0/3] smack: add file label preserve mechanism
Date: Thu, 20 Aug 2026 13:11:24 -0700 [thread overview]
Message-ID: <263920dc-392c-4a95-b7be-05de0e03f447@schaufler-ca.com> (raw)
In-Reply-To: <TY0PR06MB495733D0FB097FB83F8E707981A42@TY0PR06MB4957.apcprd06.prod.outlook.com>
On 8/20/2026 5:05 AM, Tang Peter wrote:
> Subject: Re: [RFC PATCH 0/3] smack: add file label preserve mechanism
>
> Hi Casey,
>
> Thanks again for the earlier guidance. I've dropped the preserve mechanism
> as discussed — the ecp example made the write-down flaw clear.
>
> Let me restate the concrete problem I'm still trying to solve, because
> it is
> narrower than the original patch and I want to check whether there is a
> cleaner native mechanism I'm overlooking.
>
> Context: I'm designing a channel-classification scheme for an embedded
> device (MIPS, BusyBox) where incoming files are labeled by origin — USB,
> network, and serial each map to an untrusted label (USB_Area, Net_Area,
> Serial_Area). The design goal is that a file's label encodes where it came
> from, so it stays traceable through its lifetime.
>
> The specific gap is FAT32 USB. FAT32 has no xattr support, so per-file
> labels can't be stored on the stick. The only way to label stick
> content is
> the mount-time default:
>
> mount -t vfat -o smackfsdef=USB_Area /dev/sda1 /mnt/usb
>
> which makes every file on the mount appear as USB_Area. That part works.
> The problem is the moment content leaves the stick: `cp /mnt/usb/f.txt
> /srv/data/f.txt` creates f.txt with the copying process's label, so the
> USB_Area provenance is silently lost.
>
> From your earlier reply I understand transmuting labels are the intended
> tool, and indeed copying into a transmuting quarantine directory preserves
> the label — our ingress path already does exactly that. The case I can't
> close is the later approval step: when an administrator moves a file
> out of
> the quarantine into a normal data directory, the label is lost again
> unless
> the administrator relabels explicitly.
>
> So the question is narrower than preserve: is there an established SMACK
> pattern for "a file that originated on a smackfsdef mount keeps that
> provenance across a copy or move", beyond explicit chsmack at every step?
How about trying a special program cp_usbarea which uses a SMACK64_EXEC
attribute to always run with your USB_Area label? You would need a rule
USB_Area <label-of-destination> rw
to allow the program to write in the destination directory. cp_usbarea
would need to be trusted to some level, but not to the extent a root
or CAP_MAC_ADMIN process would require.
>
> I currently solve it in userspace (a small cp wrapper that copies the
> source
> label with chsmack after the copy, which works because chsmack is
> privileged), but I'd rather not invent a mechanism if SMACK already
> has one
> for this case.
>
> Thanks for your time.
>
> Regards,
> Tang Pengke
> ------------------------------------------------------------------------
> *发件人:* Casey Schaufler <casey@schaufler-ca.com>
> *发送时间:* 2026年8月19日 0:11
> *收件人:* Tang Peter <Peter_Towne@hotmail.com>
> *抄送:* linux-security-module@vger.kernel.org
> <linux-security-module@vger.kernel.org>; Casey Schaufler
> <casey@schaufler-ca.com>
> *主题:* Re: [RFC PATCH 0/3] smack: add file label preserve mechanism
>
> On 8/18/2026 1:05 AM, Tang Peter wrote:
> > Subject: [RFC PATCH 0/3] smack: add file label preserve mechanism
> >
> > Hi Casey,
> >
> > I'm working on an embedded Linux device (MIPS, BusyBox) that uses SMACK
> > for mandatory access control, and I ran into a problem that I think is
> > worth your opinion on.
> >
> > Problem
> > -------
> > When a user copies a file with BusyBox cp, the destination file inherits
> > the *process* label rather than the *source* file's label.
>
> This is the correct and expected behavior. A process that creates
> a new file has the opportunity to put whatever data it desires in it,
> so the new file has to have the process label, regardless of any labeling
> of the source information.
>
> Cases like this are why Smack has transmuting labels. Without more
> information
> about the specifics of your directory hierarchy and labeling strategy it's
> hard to offer specific advice, but if what you have is a limited set
> of files
> that require label preservation you should be able to use that mechanism.
>
> > On desktop or
> > server systems this is solved in userspace -- GNU cp has
> > --preserve=context, and SELinux has restorecond. But on an embedded
> > device with BusyBox, neither is available, and the result is that the
> > source file's label (e.g. an untrusted "USB" label) is silently lost
> > after the copy, which breaks both access control and audit tracing.
> >
> > Proposed mechanism
> > ------------------
> > An opt-in "preserve" feature controlled via /sys/fs/smackfs/preserve
> > (default off):
> >
> > 1. smack_file_open(): when a regular file is opened O_RDONLY,
> > record its label into task_smack::smk_preserve. Shared library
> > loads under /lib/ and /usr/lib/ are skipped (path-prefix filter)
> > so ld.so does not pollute the preserve slot.
> >
> > 2. smack_inode_init_security(): if smk_preserve is set, use it as
> > the new inode's label and clear it. TRANSMUTE still takes
> > priority, so existing transmuting-directory behaviour is unchanged.
> >
> > 3. The slot is one-shot: cleared on use, on fork (cred_prepare),
> > and on exec (bprm_creds_for_exec), so it only applies to a
> > "read then create" sequence within a single process.
> >
> > This makes `cp a b`, `cat a > b`, and similar BusyBox workflows keep
> > the source label without any userspace changes.
>
> I have an evil program "ecp", which uses this mechanism. ecp opens a
> file labeled "_", and creates a new executable file /bin/xyzzy. It then
> opens a file labeled "somethingelse", which contains a malicious program.
> /bin/xyzzy is filled with the malicious program. Now, processes that
> have no access to somethingelse are exposed to the malicious program.
>
> You could restrict smk_preserve to programs with CAP_MAC_ADMIN, but
> such a process could relabel the file directly, rendering the mechanism
> unnecessary.
>
> >
> > Questions
> > ---------
> > - Does this approach make sense for SMACK, or is there an existing /
> > preferred way to solve this that I've missed?
> > - Any concerns about the one-shot slot semantics, or the /lib/ filter?
> >
> > Thanks,
> > Tang Pengke
> >
> > ---
> > security/smack/smack.h | 2 ++
> > security/smack/smack_lsm.c | 45
> > +++++++++++++++++++++++++++++++++++++++++----
> > security/smack/smackfs.c | 50
> > ++++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 93 insertions(+), 4 deletions(-)
> >
> >
> > From: Tang Pengke <peter_towne@hotmail.com>
> > Subject: [RFC PATCH 1/3] smack: add smk_preserve field to task_smack
> >
> > Add a smk_preserve pointer to struct task_smack for recording
> > the label of the last file opened read-only. Also declare the
> > global smack_preserve toggle variable.
> >
> > Signed-off-by: Tang Pengke <peter_towne@hotmail.com>
> > ---
> > security/smack/smack.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/security/smack/smack.h b/security/smack/smack.h
> > index 8ad30955e15..c6eea57cf52 100644
> > --- a/security/smack/smack.h
> > +++ b/security/smack/smack.h
> > @@ -124,6 +124,7 @@ struct task_smack {
> > struct list_head smk_rules; /* per task access rules */
> > struct mutex smk_rules_lock; /* lock for the rules */
> > struct list_head smk_relabel; /* transit allowed labels */
> > + struct smack_known *smk_preserve; /* label to preserve
> > on create */
> > };
> >
> > #define SMK_INODE_INSTANT 0x01 /* inode is instantiated */
> > @@ -325,6 +326,7 @@ extern struct smack_known *smack_unconfined;
> > #endif
> > extern int smack_ptrace_rule;
> > +extern int smack_preserve;
> > extern struct lsm_blob_sizes smack_blob_sizes;
> >
> > extern struct smack_known smack_known_floor;
> >
> >
> > From: Tang Pengke <peter_towne@hotmail.com>
> > Subject: [RFC PATCH 2/3] smack: implement file label preserve mechanism
> >
> > When smack_preserve is enabled, opening a regular file read-only
> > records its label in task_smack::smk_preserve. On the next file
> > creation (smack_inode_init_security), that label is applied to the
> > new inode -- unless TRANSMUTE takes priority.
> >
> > The preserve is one-shot:
> > - Consumed immediately on new inode creation
> > - Cleared on fork (smack_cred_prepare)
> > - Cleared on exec (smack_bprm_creds_for_exec)
> >
> > Shared library loads under /lib/ and /usr/lib/ are explicitly
> > excluded from recording, so ld.so does not pollute the preserve
> > label during exec. Non-regular files (directories, devices) are
> > also skipped.
> >
> > This enables tools like cp and 'cat > file' to create files that
> > retain the source file's label, without requiring any userspace
> > changes. The feature is disabled by default (preserve=0).
> >
> > Signed-off-by: Tang Pengke <peter_towne@hotmail.com>
> > ---
> > security/smack/smack_lsm.c | 45
> > +++++++++++++++++++++++++++++++++++++++++----
> > 1 file changed, 41 insertions(+), 4 deletions(-)
> >
> > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> > index 11f238e94..951c79d9e 100644
> > --- a/security/smack/smack_lsm.c
> > +++ b/security/smack/smack_lsm.c
> > @@ -935,6 +935,7 @@ static int smack_bprm_creds_for_exec(struct
> > linux_binprm *bprm)
> > return -EPERM;
> >
> > bsp->smk_task = isp->smk_task;
> > + bsp->smk_preserve = NULL;
> > bprm->per_clear |= PER_CLEAR_ON_SETID;
> >
> > /* Decide if this is a secure exec. */
> > @@ -1066,6 +1067,15 @@ static int smack_inode_init_security(struct
> > inode *inode, struct inode *dir,
> > }
> > }
> >
> > + /*
> > + * If a preserve label was recorded on file open, use it
> > + * for the new inode (unless TRANSMUTE already applied above).
> > + */
> > + if (tsp->smk_preserve != NULL) {
> > + issp->smk_inode = tsp->smk_preserve;
> > + tsp->smk_preserve = NULL;
> > + }
> > +
> > if (rc == 0)
> > if (xattr_dupval(xattrs, xattr_count,
> > XATTR_SMACK_SUFFIX,
> > @@ -2064,6 +2074,27 @@ static int smack_file_open(struct file *file)
> > struct smk_audit_info ad;
> > int rc;
> >
> > + if (smack_preserve && (file->f_flags & O_ACCMODE) == O_RDONLY) {
> > + char *buf;
> > + const char *path;
> > +
> > + if (!S_ISREG(inode->i_mode))
> > + goto skip_preserve;
> > +
> > + buf = kmalloc(PATH_MAX, GFP_KERNEL);
> > + if (!buf)
> > + goto skip_preserve;
> > +
> > + path = dentry_path_raw(file->f_path.dentry, buf, PATH_MAX);
> > + if (!IS_ERR(path) &&
> > + strncmp(path, "/lib/", 5) != 0 &&
> > + strncmp(path, "/usr/lib/", 9) != 0)
> > + tsp->smk_preserve = smk_of_inode(inode);
> > +
> > + kfree(buf);
> > + }
> > +skip_preserve:
> > +
> > smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_PATH);
> > smk_ad_setfield_u_fs_path(&ad, file->f_path);
> > rc = smk_tskacc(tsp, smk_of_inode(inode), MAY_READ, &ad);
> > @@ -2129,6 +2160,7 @@ static int smack_cred_prepare(struct cred *new,
> > const struct cred *old,
> > int rc;
> >
> > init_task_smack(new_tsp, old_tsp->smk_task, old_tsp->smk_task);
> > + new_tsp->smk_preserve = NULL;
> >
> > rc = smk_copy_rules(&new_tsp->smk_rules, &old_tsp->smk_rules,
> gfp);
> > if (rc != 0)
> >
> >
> > From: Tang Pengke <peter_towne@hotmail.com>
> > Subject: [RFC PATCH 3/3] smack: add /sys/fs/smackfs/preserve interface
> >
> > Expose the smack_preserve toggle via smackfs. Reading returns '0'
> > or '1'. Writing '0' or '1' toggles the feature (requires
> > CAP_MAC_ADMIN). Default is disabled (0) so existing systems are
> > unaffected.
> >
> > Signed-off-by: Tang Pengke <peter_towne@hotmail.com>
> > ---
> > security/smack/smackfs.c | 50
> > ++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> > index a3a55a25360..8379ef73cf2 100644
> > --- a/security/smack/smackfs.c
> > +++ b/security/smack/smackfs.c
> > @@ -62,6 +62,7 @@ enum smk_inos {
> > SMK_NET6ADDR = 23, /* single label IPv6 hosts */
> > #endif /* CONFIG_IPV6 */
> > SMK_RELABEL_SELF = 24, /* relabel possible without
> CAP_MAC_ADMIN */
> > + SMK_PRESERVE = 25, /* label preserve on copy */
> > };
> >
> > /*
> > @@ -2047,6 +2048,53 @@ static ssize_t smk_write_onlycap(struct file
> > *file, const char __user *buf,
> > return rc;
> > }
> >
> > +int smack_preserve;
> > +
> > +static ssize_t smk_read_preserve(struct file *filp, char __user *buf,
> > + size_t cn, loff_t *ppos)
> > +{
> > + char val[2];
> > +
> > + if (*ppos != 0)
> > + return 0;
> > +
> > + val[0] = smack_preserve ? '1' : '0';
> > + val[1] = '\n';
> > +
> > + return simple_read_from_buffer(buf, cn, ppos, val, 2);
> > +}
> > +
> > +static ssize_t smk_write_preserve(struct file *file, const char
> > __user *buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + char data;
> > +
> > + if (!smack_privileged(CAP_MAC_ADMIN))
> > + return -EPERM;
> > +
> > + if (*ppos != 0)
> > + return -EINVAL;
> > +
> > + if (copy_from_user(&data, buf, 1) != 0)
> > + return -EFAULT;
> > +
> > + if (data == '0')
> > + smack_preserve = 0;
> > + else if (data == '1')
> > + smack_preserve = 1;
> > + else
> > + return -EINVAL;
> > +
> > + return count;
> > +}
> > +
> > +static const struct file_operations smk_preserve_ops = {
> > + .read = smk_read_preserve,
> > + .write = smk_write_preserve,
> > + .llseek = default_llseek,
> > +};
> > +
> > static const struct file_operations smk_onlycap_ops = {
> > .open = smk_open_onlycap,
> > .read = seq_read,
> > @@ -2933,6 +2981,8 @@ static int smk_fill_super(struct super_block
> > *sb, struct fs_context *fc)
> > [SMK_RELABEL_SELF] = {
> > "relabel-self", &smk_relabel_self_ops,
> > S_IRUGO|S_IWUGO},
> > + [SMK_PRESERVE] = {
> > + "preserve", &smk_preserve_ops, S_IRUGO|S_IWUSR},
> > /* last one */
> > {""}
> > };
next prev parent reply other threads:[~2026-08-20 20:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <TY0PR06MB49571F55B361203419222EDA81A62@TY0PR06MB4957.apcprd06.prod.outlook.com>
2026-08-18 16:11 ` [RFC PATCH 0/3] smack: add file label preserve mechanism Casey Schaufler
[not found] ` <TY0PR06MB495733D0FB097FB83F8E707981A42@TY0PR06MB4957.apcprd06.prod.outlook.com>
2026-08-20 20:11 ` Casey Schaufler [this message]
[not found] ` <TY0PR06MB4957E1715F84D092A7B69CD481A02@TY0PR06MB4957.apcprd06.prod.outlook.com>
2026-08-24 17:57 ` 回复: 回复: " Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=263920dc-392c-4a95-b7be-05de0e03f447@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=Peter_Towne@hotmail.com \
--cc=gaolong@yhkylin.cn \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox