lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 19 Sep 2007 10:28:32 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	David Howells <dhowells@...hat.com>, viro@....linux.org.uk,
	hch@...radead.org, Trond.Myklebust@...app.com, sds@...ho.nsa.gov,
	casey@...aufler-ca.com
Cc:	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	linux-security-module@...r.kernel.org, dhowells@...hat.com
Subject: Re: [PATCH 2/3] CRED: Split the task security data and move part of it into struct cred


--- David Howells <dhowells@...hat.com> wrote:

> Move into the cred struct the part of the task security data that defines how
> a
> task acts upon an object.  The part that defines how something acts upon a
> task
> remains attached to the task.

This seems to me to be an unnatural and inappropriate separation.
Move the whole of the security blob into the cred if you must have
a cred (which I was soooo glad Linux didn't have after having dealt
with it in Solaris) rather than having two blobs to deal with. If an
LSM requires a different treatment between when a task is a subject
and when it is an object the LSM should handle that itself.

> For SELinux this requires some of task_security_struct to be split off into
> cred_security_struct which is then attached to struct cred.  Note that the
> contents of cred_security_struct may not be changed without the generation of
> a
> new struct cred.
> 
> The split is as follows:
> 
>  (*) create_sid, keycreate_sid and sockcreate_sid just move across.
> 
>  (*) sid is split into victim_sid - which remains - and action_sid - which
>      migrates.
> 
>  (*) osid, exec_sid and ptrace_sid remain.
> 
> victim_sid is the SID used to govern actions upon the task.  action_sid is
> used
> to govern actions made by the task.

So put all these fields into one blob and attach them to the cred.
Actually, if you put all these fields in the task blob maybe you
don't need to do your COW thing at all.
 



Casey Schaufler
casey@...aufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ