Re: [PATCH v5 00/38] LSM: Module stacking for SARA and Landlock
On Mon, 7 Jan 2019, Kees Cook wrote: > On Tue, Dec 11, 2018 at 1:19 PM Kees Cook wrote: > > > > On Tue, Dec 11, 2018 at 10:57 AM James Morris wrote: > > > > > > On Tue, 4 Dec 2018, Kees Cook wrote: > > > > > > > On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler > > > > wrote: > > > > > v5: Include Kees Cook's rework of the lsm command > > > > > line interface. Stacking is not conditional. > > > > > > > > Can you resend this series with corrected "From:" lines in the body, > > > > etc? > > > > > > > > Beyond that, I obviously like it. James, what's needed for this to move > > > > forward? > > > > > > If there are no outstanding issues, I plan to merge this for 4.21. > > > > Yeah, it looks good to me. (Excepting getting the authorship sorted.) > > I didn't see this actually get merged? Was there something that needed > fixing? Should I send you a direct pull request for v5.1? Yep, please send a new pull request. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v5 00/38] LSM: Module stacking for SARA and Landlock
On Tue, 4 Dec 2018, Kees Cook wrote: > On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler > wrote: > > v5: Include Kees Cook's rework of the lsm command > > line interface. Stacking is not conditional. > > Can you resend this series with corrected "From:" lines in the body, etc? > > Beyond that, I obviously like it. James, what's needed for this to move > forward? If there are no outstanding issues, I plan to merge this for 4.21. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v4 14/19] LSM: Infrastructure management of the inode security
On Fri, 21 Sep 2018, Kees Cook wrote:
> On Fri, Sep 21, 2018 at 5:19 PM, Casey Schaufler
> wrote:
> > + * lsm_early_inode - during initialization allocate a composite inode blob
> > + * @inode: the inode that needs a blob
> > + *
> > + * Allocate the inode blob for all the modules if it's not already there
> > + */
> > +void lsm_early_inode(struct inode *inode)
> > +{
> > + int rc;
> > +
> > + if (inode == NULL)
> > + panic("%s: NULL inode.\n", __func__);
> > + if (inode->i_security != NULL)
> > + return;
> > + rc = lsm_inode_alloc(inode);
> > + if (rc)
> > + panic("%s: Early inode alloc failed.\n", __func__);
> > +}
>
> I'm still advising against using panic(), but I'll leave it up to James.
>
Calling panic() is not appropriate here. Perhaps if it was during
boot-time initialization of LSM infrastructure, but not on the fly.
Use a WARN_ONCE then propagate the error back and fail the operation.
--
James Morris
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v4 00/19] LSM: Module stacking for SARA and Landlock
On Sun, 23 Sep 2018, Casey Schaufler wrote: > > How do you plan to handle LKM-based LSMs? > > My position all along has been that I don't plan to handle LKM > based LSMs, but that I won't do anything to prevent someone else > from adding them later. I believe that I've done that. Several > designs, including a separate list for dynamically loaded modules > have been proposed. I think some of those would work. Dynamically loadable LSMs are a bad idea, per several previous discussions. As a general design concept, kernel security mechanisms should be invoked during boot, so we can reason about the overall state of the system at a given point. In any case, we do not need to take dynamic LSMs into account at this stage. We don't build infrastructure for non-existent features. ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v5 5/5] sidechannel: Linux Security Module for sidechannel
On Fri, 28 Sep 2018, Jann Horn wrote: > > so with this hard-coded logic, you are saying this case is > > 'safe' in a sidechannel context. > > > > Which hints at the deeper issue that containers are a userland > > abstraction. Protection of containers needs to be defined by userland > > policy. > > Or just compare mount namespaces additionally/instead. I think that > containers will always use those, because AFAIK nobody uses chroot() > for containers, given that the kernel makes absolutely no security > guarantees about chroot(). We can't define this in the kernel. It has no concept of containers. People utilize some combination of namespaces and cgroups and call them containers, but we can't make assumptions from the kernel on what any of this means from a security point of view, and hard-code kernel policy based on those assumptions. This is violating the principal of separating mechanism and policy, and also imposing semantics across the kernel/user boundary. The latter creates an ABI which we can then never break. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v5 5/5] sidechannel: Linux Security Module for sidechannel
On Thu, 27 Sep 2018, Casey Schaufler wrote: > On 9/27/2018 2:45 PM, James Morris wrote: > > On Wed, 26 Sep 2018, Casey Schaufler wrote: > > > >> + /* > >> + * Namespace checks. Considered safe if: > >> + * cgroup namespace is the same > >> + * User namespace is the same > >> + * PID namespace is the same > >> + */ > >> + if (current->nsproxy) > >> + ccgn = current->nsproxy->cgroup_ns; > >> + if (p->nsproxy) > >> + pcgn = p->nsproxy->cgroup_ns; > >> + if (ccgn != pcgn) > >> + return -EACCES; > >> + if (current->cred->user_ns != p->cred->user_ns) > >> + return -EACCES; > >> + if (task_active_pid_ns(current) != task_active_pid_ns(p)) > >> + return -EACCES; > >> + return 0; > > I really don't like the idea of hard-coding namespace security semantics > > in an LSM. Also, I'm not sure if these semantics make any sense. > > Checks on namespaces where explicitly requested. By whom and what is the rationale? -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
RE: [PATCH v5 5/5] sidechannel: Linux Security Module for sidechannel
On Thu, 27 Sep 2018, Schaufler, Casey wrote: > > > On 9/27/2018 2:45 PM, James Morris wrote: > > > > On Wed, 26 Sep 2018, Casey Schaufler wrote: > > > > > > > >> + /* > > > >> + * Namespace checks. Considered safe if: > > > >> + * cgroup namespace is the same > > > >> + * User namespace is the same > > > >> + * PID namespace is the same > > > >> + */ > > > >> + if (current->nsproxy) > > > >> + ccgn = current->nsproxy->cgroup_ns; > > > >> + if (p->nsproxy) > > > >> + pcgn = p->nsproxy->cgroup_ns; > > > >> + if (ccgn != pcgn) > > > >> + return -EACCES; > > > >> + if (current->cred->user_ns != p->cred->user_ns) > > > >> + return -EACCES; > > > >> + if (task_active_pid_ns(current) != task_active_pid_ns(p)) > > > >> + return -EACCES; > > > >> + return 0; > > > > I really don't like the idea of hard-coding namespace security semantics > > > > in an LSM. Also, I'm not sure if these semantics make any sense. > > > > > > Checks on namespaces where explicitly requested. > > > > By whom and what is the rationale? > > The rationale is to protect containers. Since those closest thing > there is to a definition of containers is "uses namespaces" that > becomes the focus. Separating them out does not make too much > sense as I would expect someone concerned with one to be concerned > with all. A lot of people will not be using user namespaces due to security concerns, so with this hard-coded logic, you are saying this case is 'safe' in a sidechannel context. Which hints at the deeper issue that containers are a userland abstraction. Protection of containers needs to be defined by userland policy. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v4 04/19] SELinux: Remove cred security blob poisoning
On Fri, 21 Sep 2018, Casey Schaufler wrote: > The SELinux specific credential poisioning only makes sense > if SELinux is managing the credentials. As the intent of this > patch set is to move the blob management out of the modules > and into the infrastructure, the SELinux specific code has > to go. The poisioning could be introduced into the infrastructure > at some later date. If it's useful, it should be incorporated into core LSM, otherwise that's a regression for SELinux. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v5 5/5] sidechannel: Linux Security Module for sidechannel
On Wed, 26 Sep 2018, Casey Schaufler wrote: > + /* > + * Namespace checks. Considered safe if: > + * cgroup namespace is the same > + * User namespace is the same > + * PID namespace is the same > + */ > + if (current->nsproxy) > + ccgn = current->nsproxy->cgroup_ns; > + if (p->nsproxy) > + pcgn = p->nsproxy->cgroup_ns; > + if (ccgn != pcgn) > + return -EACCES; > + if (current->cred->user_ns != p->cred->user_ns) > + return -EACCES; > + if (task_active_pid_ns(current) != task_active_pid_ns(p)) > + return -EACCES; > + return 0; I really don't like the idea of hard-coding namespace security semantics in an LSM. Also, I'm not sure if these semantics make any sense. It least make it user configurable. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock
On Thu, 13 Sep 2018, Casey Schaufler wrote: > On 9/13/2018 4:57 PM, Kees Cook wrote: > > On Thu, Sep 13, 2018 at 4:51 PM, Casey Schaufler > > wrote: > >> On 9/13/2018 4:06 PM, Kees Cook wrote: > >>> - what order should any stacking happen? Makefile? security=? > >> Makefile by default. > > Okay, if ordering is by Makefile and everyone dislikes my > > $lsm.enabled=0/1 thing, then these mean the same thing: > > > > security=selinux,tomoyo > > security=tomoyo,selinux > > > > i.e. order of security= is _ignored_ in favor of the Makefile ordering. > > No, I think that the two lines above should have a different > execution order. If we really need to specify multiple modules > at boot time that is what makes the most sense. Agreed. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v2 00/10] LSM: Module stacking in support of S.A.R.A and Landlock
Adding the SARA and LandLock authors for review & comment. Salvatore & Mickaël: does this patchset meet your needs for merging to mainline? On Tue, 11 Sep 2018, Casey Schaufler wrote: > LSM: Module stacking in support of S.A.R.A and Landlock > > v2: Reduce the patchset to what is required to support > the proposed S.A.R.A. and LandLock security modules > > The S.A.R.A. security module is intended to be used > in conjunction with other security modules. It requires > state to be maintained for the credential, which > in turn requires a mechanism for sharing the credential > security blob. The module also requires mechanism for > user space manipulation of the credential information, > hence an additional subdirectory in /proc/.../attr. > > The LandLock security module provides user configurable > policy in the secmark mechanism. It requires data in > the credential, file and inode security blobs. For this > to be used along side the existing "major" security > modules mechanism for sharing these blobs is provided. > > A side effect of providing sharing of the crendential > security blob is that the TOMOYO module can be used at > the same time as the other "major" modules. > > The mechanism for configuring which security modules are > enabled has to change when stacking in enabled. Any > module that uses just the security blobs that are shared > can be selected. Additionally, one other "major" module > can be selected. > > The security module stacking issues around networking and > IPC are not addressed here as they are beyond what is > required for TOMOYO, S.A.R.A and LandLock. > > git://github.com/cschaufler/lsm-stacking.git#stacking-4.19-rc2-saralock > > Signed-off-by: Casey Schaufler > --- > Documentation/admin-guide/LSM/index.rst | 23 ++- > fs/proc/base.c | 64 ++- > fs/proc/internal.h | 1 + > include/linux/lsm_hooks.h | 20 ++- > include/linux/security.h| 15 +- > kernel/cred.c | 13 -- > security/Kconfig| 92 ++ > security/apparmor/domain.c | 2 +- > security/apparmor/include/cred.h| 24 ++- > security/apparmor/include/file.h| 9 +- > security/apparmor/include/lib.h | 4 + > security/apparmor/lsm.c | 53 -- > security/apparmor/task.c| 6 +- > security/security.c | 293 > ++-- > security/selinux/hooks.c| 215 --- > security/selinux/include/objsec.h | 37 +++- > security/selinux/selinuxfs.c| 5 +- > security/selinux/xfrm.c | 4 +- > security/smack/smack.h | 42 - > security/smack/smack_access.c | 4 +- > security/smack/smack_lsm.c | 283 +++--- > security/smack/smackfs.c| 18 +- > security/tomoyo/common.h| 31 +++- > security/tomoyo/domain.c| 4 +- > security/tomoyo/securityfs_if.c | 15 +- > security/tomoyo/tomoyo.c| 57 +-- > 26 files changed, 899 insertions(+), 435 deletions(-) > -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v2 00/10] LSM: Module stacking in support of S.A.R.A and Landlock
On Tue, 11 Sep 2018, Casey Schaufler wrote: > LSM: Module stacking in support of S.A.R.A and Landlock Please help prevent RSI and shorten this to SARA. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v1 00/22] LSM: Full security module stacking
On Tue, 14 Aug 2018, Casey Schaufler wrote: > On 8/14/2018 4:22 PM, Jordan Glover wrote: > > On August 14, 2018 8:28 PM, Casey Schaufler wrote: > > > > On the other hand there is concern that those security modules might > > be abandoned if they have to wait until everything is finished :) > > There is some truth to that. If we can get commitment from the developers > of those security module to push for getting upstream, a statement of > intent to support additional modules (e.g. Landlock, S.A.R.A.) from a > significant distribution (e.g. Fedora, Ubuntu, SuSE) and ACKs from the > maintainers of the existing modules we should be able to breeze right in. > Sounds reasonable. Please focus on what's needed for Landlock and SARA. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: BUG: Mount ignores mount options
On Mon, 13 Aug 2018, Al Viro wrote: > On Mon, Aug 13, 2018 at 09:48:53AM -0700, Andy Lutomirski wrote: > > Are there cases I'm missing? It sounds like the API could be improved > > to fully model the last case, and everything will work nicely. > > You know, that's starting to remind of this little gem of Borges: > http://www.alamut.com/subj/artiface/language/johnWilkins.html > Especially the delightful (fake) quote contained in there: > [...] it is written that the animals are divided into: > (a) belonging to the emperor, > (b) embalmed, > (c) tame, > (d) sucking pigs, > (e) sirens, > (f) fabulous, > (g) stray dogs, > (h) included in the present classification, > (i) frenzied, > (j) innumerable, > (k) drawn with a very fine camelhair brush, > (l) et cetera, > (m) having just broken the water pitcher, > (n) that from a long way off look like flies. Coincidentally, this was also the model for Linux capabilities. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v1 00/22] LSM: Full security module stacking
On Mon, 16 Jul 2018, Casey Schaufler wrote: > LSM: Full security module stacking > > I'm calling this v1 not because it's the first version > I've put out but because it's the first version I'm getting > serious external pressure to get upstream. >From whom? -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [-next PATCH] security: use octal not symbolic permissions
On Mon, 11 Jun 2018, Casey Schaufler wrote: > If you want to break this up by security module I would take > the Smack part as soon as James does the tree update. If James > wants to take the whole thing at once you can add my: > > Acked-by: Casey Schaufler > > for the Smack changes. It's probably simplest for me to take them as one patch. -- James Morris ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH 00/23] LSM: Full security module stacking
On Tue, 15 May 2018, Casey Schaufler wrote:
> Both SELinux and Smack use netlbl_sock_setattr() in their socket_post_create()
> hooks to establish the CIPSO to use if nothing else interferes. An unfortunate
> artifact of the Smack "ambient label" implementation is that the default
> configuration is going to delete the netlbl attribute for the floor ("_")
> label. This will conflict with any value that SELinux sets. :( Smack clearly
> needs to have it's use of netlabel revised, and that is work that's going on
> in parallel with stacking. That, however, is not an infrastructure issue, it's
> an issue with how the two modules use the facilities.
Can this kind of problem be prevented at the API level? i.e. ensure you
can't accidentally conflict with another LSM's use of the label here?
--
James Morris
<jmor...@namei.org>
Re: [PATCH v2 0/4] Introduce LSM-hook for socketpair(2)
On Fri, 4 May 2018, David Herrmann wrote: > Hi > > This is v2 of the socketpair(2) LSM hook introduction. Thanks, all applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general -- James Morris <jmor...@namei.org>
Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)
On Wed, 25 Apr 2018, Paul Moore wrote: > On Wed, Apr 25, 2018 at 2:44 PM, James Morris <jmor...@namei.org> wrote: > > On Mon, 23 Apr 2018, David Herrmann wrote: > >> This patch series tries to close this gap and makes both behave the > >> same. A new LSM-hook is added which allows LSMs to cache the correct > >> peer information on newly created socket-pairs. > > > > Looks okay to me. > > > > Once it's respun with the Smack backend and maybe the hook name change, > > I'll merge this unless DaveM wants it to go in via his networking tree. > > Note my objection to the hook placement in patch 2/3; I think we > should move the hook out of the AF_UNIX layer and up into the socket > layer. I vote for this as it maintains the intended abstraction of the socket API. -- James Morris <jmor...@namei.org>
Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)
On Mon, 23 Apr 2018, David Herrmann wrote: > This patch series tries to close this gap and makes both behave the > same. A new LSM-hook is added which allows LSMs to cache the correct > peer information on newly created socket-pairs. Looks okay to me. Once it's respun with the Smack backend and maybe the hook name change, I'll merge this unless DaveM wants it to go in via his networking tree. -- James Morris <jmor...@namei.org>
Re: SELinux Namespace on bind mounted files
On Thu, 8 Mar 2018, Daniel Walsh wrote: > I am not a big fan of Namespaced SELinux. I think it complicates things and > will confuse people. I would think a better solution would be to run your > container with a different type so that you could allow access t othese file > types. > > It would be a lot easier to create a type based on container-selinux policy > and just run your container with it. > > > podman run -ti --security-opt label=type:mycontianer_t -v /SRC:/DEST IMAGE > > Or if you must > > docker run -ti --security-opt label=type:mycontianer_t -v /SRC:/DEST IMAGE I think it depends on your use-case. If you want an OS-like privileged container, then the current solution of having SELinux appear disabled in the container is inadequate for many users. It is also trivially possible to access and modify global SELinux state from there. -- James Morris <jmor...@namei.org>
Re: [PATCH] usb, signal, security: only pass the cred, not the secid, to kill_pid_info_as_cred and security_task_kill
On Tue, 6 Mar 2018, Casey Schaufler wrote: > On 3/6/2018 11:01 AM, Paul Moore wrote: > > On Fri, Sep 8, 2017 at 6:09 PM, James Morris <jmor...@namei.org> wrote: > >> On Fri, 8 Sep 2017, Paul Moore wrote: > >>> Looks fine to me from a SELinux perspective. If Casey and John are > >>> happy with this I can volunteer to pull it into the selinux/next tree > >>> (once the merge window closes), otherwise if someone else wants to > >>> merge this my ack is below. > >> As this impacts multiple LSMs, I'd prefer to take it via my tree. > > What happened to this James? As best I can tell there were never any > > objections, and plenty of ACKs, but I don't see it in Linus' tree. > > I'll extend my offer to merge it, but I know you expressed a desire to > > pull this via your tree. > > I was also surprised that it had not been included. > > > > > * > > http://kernsec.org/pipermail/linux-security-module-archive/2017-September/003156.html > > Oops, Now applied to: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general and next-testing -- James Morris <jmor...@namei.org>
Re: [PATCH 2/2] selinux: wrap AVC state
On Mon, 5 Mar 2018, Stephen Smalley wrote: > Wrap the AVC state within the selinux_state structure and > pass it explicitly to all AVC functions. The AVC private state > is encapsulated in a selinux_avc structure that is referenced > from the selinux_state. > > This change should have no effect on SELinux behavior or > APIs (userspace or LSM). > > Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov> Reviewed-by: James Morris <james.mor...@microsoft.com> -- James Morris <jmor...@namei.org>
Re: [PATCH 1/2] selinux: wrap selinuxfs state
On Mon, 5 Mar 2018, Stephen Smalley wrote: > Move global selinuxfs state to a per-instance structure (selinux_fs_info), > and include a pointer to the selinux_state in this structure. > Pass this selinux_state to all security server operations, thereby > ensuring that each selinuxfs instance presents a view of and acts > as an interface to a particular selinux_state instance. > > This change should have no effect on SELinux behavior or APIs > (userspace or LSM). It merely wraps the selinuxfs global state, > links it to a particular selinux_state (currently always the single > global selinux_state) and uses that state for all operations. > > Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov> Reviewed-by: James Morris <james.mor...@microsoft.com> -- James Morris <jmor...@namei.org>
Re: [PATCH] selinux: skip bounded transition processing if the policy isn't loaded
On Wed, 6 Dec 2017, Paul Moore wrote: > From: Paul Moore <p...@paul-moore.com> > > We can't do anything reasonable in security_bounded_transition() if we > don't have a policy loaded, and in fact we could run into problems > with some of the code inside expecting a policy. Fix these problems > like we do many others in security/selinux/ss/services.c by checking > to see if the policy is loaded (ss_initialized) and returning quickly > if it isn't. > > Reported-by: syzbot <syzkaller-b...@googlegroups.com> > Signed-off-by: Paul Moore <p...@paul-moore.com> > Acked-by: Stephen Smalley <s...@tycho.nsa.gov> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: KASAN: slab-out-of-bounds Read in strcmp
On Sun, 3 Dec 2017, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > which will allow strcmp() to trigger out of bound read when "size" is > > larger than strlen(initial_sid_to_string[i]). > > Oops. "smaller" than. > > > > > Thus, I guess the simplest fix is to use strncmp() instead of strcmp(). > > Can somebody test below patch? (My CentOS 7 environment does not support > enabling SELinux in linux.git . Userspace tool is too old to support?) You mean enabling KASAN? Yep, you need gcc 4.9.2 or better. Recent Fedora has it. -- James Morris <james.l.mor...@oracle.com>
Re: [BUG] kernel stack corruption during/after Netlabel error
On Thu, 30 Nov 2017, Eric Dumazet wrote: > On Wed, 2017-11-29 at 19:16 -0800, Casey Schaufler wrote: > > On 11/29/2017 4:31 PM, James Morris wrote: > > > On Wed, 29 Nov 2017, Casey Schaufler wrote: > > > > > > > I see that there is a proposed fix later in the thread, but I > > > > don't see > > > > the patch. Could you send it to me, so I can try it on my > > > > problem? > > > > > > Forwarded off-list. > > > > The patch does fix the problem I was seeing in Smack. > > Can you guys test the following more complete patch ? > > It should cover IPv4 and IPv6, and also the corner cases. Tested-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH] selinux: ensure the context is NULL terminated in security_context_to_sid_core()
On Thu, 30 Nov 2017, Paul Moore wrote: > From: Paul Moore <p...@paul-moore.com> > > The syzbot/syzkaller automated tests found a problem in > security_context_to_sid_core() during early boot (before we load the > SELinux policy) where we could potentially feed context strings without > NULL terminators into the strcmp() function. > > We already guard against this during normal operation (after the SELinux > policy has been loaded) by making a copy of the context strings and > explicitly adding a NULL terminator to the end. The patch extends this > protection to the early boot case (no loaded policy) by moving the context > copy earlier in security_context_to_sid_core(). > > Reported-by: syzbot <syzkal...@googlegroups.com> > Signed-off-by: Paul Moore <p...@paul-moore.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [BUG] kernel stack corruption during/after Netlabel error
On Wed, 29 Nov 2017, Casey Schaufler wrote: > I see that there is a proposed fix later in the thread, but I don't see > the patch. Could you send it to me, so I can try it on my problem? Forwarded off-list. Interestingly, I didn't see the KASAN output email from Stephen here. -- James Morris <james.l.mor...@oracle.com>
Re: [BUG] kernel stack corruption during/after Netlabel error
On Wed, 29 Nov 2017, Eric Dumazet wrote:
> On Wed, 2017-11-29 at 12:23 -0800, Eric Dumazet wrote:
> >
> > I suspect this exposes an ancient bug, caused by fact that TCP moves
> > IP[6]CB in skb->cb[]
> >
> > Basically the 2nd tcp_filter() added in commit
> > 8fac365f63c866a00015fa13932d8ffc584518b8
> > ("tcp: Add a tcp_filter hook before handle ack packet") was not
> > expecting selinux code being called a 2nd time,
> > while skb->cb[] has been mangled [1]
> >
> > [1]
> > memmove(_SKB_CB(skb)->header.h4, IPCB(skb),
> > sizeof(struct inet_skb_parm));
>
> Please try this fix for IPv4 (a similar patch will be needed for IPv6)
>
> net/ipv4/tcp_ipv4.c | 51 ++
> 1 file changed, 32 insertions(+), 19 deletions(-)
Works for me, no crashes with the testsuite running in a loop.
Tested-by: James Morris <james.l.mor...@oracle.com>
--
James Morris
<james.l.mor...@oracle.com>
[BUG] kernel stack corruption during/after Netlabel error
I'm seeing a kernel stack corruption bug (detected via gcc) when running the SELinux testsuite on a 4.15-rc1 kernel, in the 2nd inet_socket test: https://github.com/SELinuxProject/selinux-testsuite/blob/master/tests/inet_socket/test # Verify that unauthorized client cannot communicate with the server. $result = system "runcon -t test_inet_bad_client_t -- $basedir/client stream 127.0.0.1 65535 2>&1"; This correctlly causes an access control error in the Netlabel code, and the bug seems to be triggered during the ICMP send: [ 339.806024] SELinux: failure in selinux_parse_skb(), unable to parse packet [ 339.822505] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 81745af5 [ 339.822505] [ 339.852250] CPU: 4 PID: 3642 Comm: client Not tainted 4.15.0-rc1-test #15 [ 339.868498] Hardware name: LENOVO 10FGS0VA1L/30BC, BIOS FWKT68A 01/19/2017 [ 339.885060] Call Trace: [ 339.896875] [ 339.908103] dump_stack+0x63/0x87 [ 339.920645] panic+0xe8/0x248 [ 339.932668] ? ip_push_pending_frames+0x33/0x40 [ 339.946328] ? icmp_send+0x525/0x530 [ 339.958861] ? kfree_skbmem+0x60/0x70 [ 339.971431] __stack_chk_fail+0x1b/0x20 [ 339.984049] icmp_send+0x525/0x530 [ 339.996205] ? netlbl_skbuff_err+0x36/0x40 [ 340.008997] ? selinux_netlbl_err+0x11/0x20 [ 340.021816] ? selinux_socket_sock_rcv_skb+0x211/0x230 [ 340.035529] ? security_sock_rcv_skb+0x3b/0x50 [ 340.048471] ? sk_filter_trim_cap+0x44/0x1c0 [ 340.061246] ? tcp_v4_inbound_md5_hash+0x69/0x1b0 [ 340.074562] ? tcp_filter+0x2c/0x40 [ 340.086400] ? tcp_v4_rcv+0x820/0xa20 [ 340.098329] ? ip_local_deliver_finish+0x71/0x1a0 [ 340.111279] ? ip_local_deliver+0x6f/0xe0 [ 340.123535] ? ip_rcv_finish+0x3a0/0x3a0 [ 340.135523] ? ip_rcv_finish+0xdb/0x3a0 [ 340.147442] ? ip_rcv+0x27c/0x3c0 [ 340.158668] ? inet_del_offload+0x40/0x40 [ 340.170580] ? __netif_receive_skb_core+0x4ac/0x900 [ 340.183285] ? rcu_accelerate_cbs+0x5b/0x80 [ 340.195282] ? __netif_receive_skb+0x18/0x60 [ 340.207288] ? process_backlog+0x95/0x140 [ 340.218948] ? net_rx_action+0x26c/0x3b0 [ 340.230416] ? __do_softirq+0xc9/0x26a [ 340.241625] ? do_softirq_own_stack+0x2a/0x40 [ 340.253368] [ 340.262673] ? do_softirq+0x50/0x60 [ 340.273450] ? __local_bh_enable_ip+0x57/0x60 [ 340.285045] ? ip_finish_output2+0x175/0x350 [ 340.296403] ? ip_finish_output+0x127/0x1d0 [ 340.307665] ? nf_hook_slow+0x3c/0xb0 [ 340.318230] ? ip_output+0x72/0xe0 [ 340.328524] ? ip_fragment.constprop.54+0x80/0x80 [ 340.340070] ? ip_local_out+0x35/0x40 [ 340.350497] ? ip_queue_xmit+0x15c/0x3f0 [ 340.361060] ? __kmalloc_reserve.isra.40+0x31/0x90 [ 340.372484] ? __skb_clone+0x2e/0x130 [ 340.382633] ? tcp_transmit_skb+0x558/0xa10 [ 340.393262] ? tcp_connect+0x938/0xad0 [ 340.403370] ? ktime_get_with_offset+0x4c/0xb0 [ 340.414206] ? tcp_v4_connect+0x457/0x4e0 [ 340.424471] ? __inet_stream_connect+0xb3/0x300 [ 340.435195] ? inet_stream_connect+0x3b/0x60 [ 340.445607] ? SYSC_connect+0xd9/0x110 [ 340.455455] ? __audit_syscall_entry+0xaf/0x100 [ 340.466112] ? syscall_trace_enter+0x1d0/0x2b0 [ 340.476636] ? __audit_syscall_exit+0x209/0x290 [ 340.487151] ? SyS_connect+0xe/0x10 [ 340.496453] ? do_syscall_64+0x67/0x1b0 [ 340.506078] ? entry_SYSCALL64_slow_path+0x25/0x25 [ 340.516693] Kernel Offset: disabled [ 340.526393] Rebooting in 11 seconds.. This is mostly reliable, and I'm only seeing it on bare metal (not in a virtualbox vm). The SELinux skb parse error at the start only sometimes appears, and looking at the code, I suspect some kind of memory corruption being the cause at that point (basic packet header checks). I bisected the bug down to the following change: commit bffa72cf7f9df842f0016ba03586039296b4caaf Author: Eric Dumazet <eduma...@google.com> Date: Tue Sep 19 05:14:24 2017 -0700 net: sk_buff rbnode reorg ... Anyone else able to reproduce this, or have any ideas on what's happening? - James -- James Morris <james.l.mor...@oracle.com>
[RFC][PATCH][v0.2] selinuxns: extend namespace support to security.selinux xattrs
This is an updated version of the patch which I first posted here:
http://kernsec.org/pipermail/linux-security-module-archive/2017-October/004053.html
I've incorporated some of the feedback provided, as follows:
1. The init namespace is now an empty string, rather than a hidden "init".
2. The ".ns." field for namespaced SELinux xattrs has been removed.
3. Namespace names are now hierarchical, and always include parent
namespace names preceding the current namespace.
As before, this works transparently for normal applications.
Some usage examples with this patch:
- Create a namespace "VM1":
# echo VM1 > /sys/fs/selinux/unshare
# unshare -m -n
# umount /sys/fs/selinux && mount -t selinuxfs none /sys/fs/selinux &&
load_policy
# runcon unconfined_u:unconfined_r:unconfined_t:s0:c0.c1023 /bin/bash
# setenforce 1
# cat /sys/fs/selinux/unshare
VM1
- Note that the current directory appears unlabeled:
# ls -dZ
drwxr-xr-x. root root system_u:object_r:unlabeled_t:s0 .
- If you create a file, it will also thus be unlabeled:
# touch b
# ls -Z
-rw-r--r--. root root unconfined_u:object_r:unlabeled_t:s0 b
- With the current code, you need to manually label the current directory
if you want labeling to work correctly:
# restorecon -v .
restorecon reset /root/selinux/test context
system_u:object_r:unlabeled_t:s0->system_u:object_r:admin_home_t:s0
# touch c
# ls -lZ
-rw-r--r--. root root unconfined_u:object_r:unlabeled_t:s0 b
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 c
- The on-disk label looks like this:
# getfattr -d -m . c
# file: c
security.selinux.VM1="unconfined_u:object_r:admin_home_t:s0"
- Now, create a nested namespace, "VM2":
# echo VM2 > /sys/fs/selinux/unshare
# unshare -m -n
# umount /sys/fs/selinux && mount -t selinuxfs none /sys/fs/selinux &&
load_policy
# runcon unconfined_u:unconfined_r:unconfined_t:s0:c0.c1023 /bin/bash
# setenforce 1
# cat /sys/fs/selinux/unshare
VM1.VM2
- Label .:
# restorecon -v .
restorecon reset /root/selinux/test context
system_u:object_r:unlabeled_t:s0->system_u:object_r:admin_home_t:s0
- Create a new file (note files from parent namespace are unlabled in this
one):
# touch d
# ls -Z
-rw-r--r--. root root system_u:object_r:unlabeled_t:s0 b
-rw-r--r--. root root system_u:object_r:unlabeled_t:s0 c
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 d
- Relabel the file:
# chcon -t etc_t d
# ls -Z d
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0 d
- View the on-disk label:
# getfattr -d -m . d
# file: d
security.selinux.VM1.VM2="unconfined_u:object_r:etc_t:s0"
There's a lot more work to do but I figured it would be useful for folk to
see the hierarchical namespacing changes. Feedback welcome!
Next TODO items:
- Perform labeling of files in ancestor namespaces upon creation in a
child namespace.
- Label inheritence & label sharing (both ro/rw).
---
>From 91bcb0b9fe058d9b7b0de1d5a1c22e5e7303989a Mon Sep 17 00:00:00 2001
From: James Morris <james.l.mor...@oracle.com>
Date: Tue, 21 Nov 2017 19:45:22 +1100
Subject: [PATCH] selinuxns: extend namespace support to security.selinux
xattrs
RFC v0.2
Signed-off-by: James Morris <james.l.mor...@oracle.com>
---
fs/xattr.c| 12 +++--
include/linux/lsm_hooks.h | 2 +
include/linux/security.h | 6 +++
include/linux/xattr.h | 2 +-
security/integrity/evm/evm_crypto.c | 2 +-
security/integrity/ima/ima_appraise.c | 2 +-
security/security.c | 6 +++
security/selinux/hooks.c | 95 +++
security/selinux/include/security.h | 7 ++-
security/selinux/selinuxfs.c | 63 ++-
security/smack/smack_lsm.c| 2 +-
11 files changed, 159 insertions(+), 40 deletions(-)
diff --git a/fs/xattr.c b/fs/xattr.c
index 4424f7f..d8107b7 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -157,6 +157,7 @@
*
* @dentry - object to perform setxattr on
* @name - xattr name to set
+ * @nsname - namespaced xattr name, use instead of @name if set
* @value - value to set @name to
* @size - size of @value
* @flags - flags to pass into filesystem operations
@@ -168,7 +169,7 @@
* permission checks.
*/
int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
- const void *value, size_t size, int flags)
+ const char *nsname, const void *value, size_t size, int flags)
{
struct inode *inode = dentry->d_inode;
int error = -EAGAIN;
@@ -178,7 +179,8 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char
*name,
if (issec)
inode->i_flags &= ~S_NOSEC;
if (inode->i_opflags & IOP_XATTR) {
- error = __vfs_setxattr(dentry, inode, name, value,
Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs
On Mon, 13 Nov 2017, Stephen Smalley wrote: > Was also wondering if the name read for the init namespace ought to > just be the empty string instead of the magic "init" value to make it > consistent with the fact that there is no xattr suffix. Makes sense. It could also be "security.selinux", and always exactly match the xattr name. -- James Morris <james.l.mor...@oracle.com>
Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs
On Tue, 31 Oct 2017, Stephen Smalley wrote: > This btw would be a bit cleaner if we dropped the .ns. portion of the > name, such that we would have: > security.selinux # xattr name in the init namespace > security.selinux.vmN # xattr name in the vmN namespace > security.selinux.vmN.vmM # xattr name in the vmN.vmM namespace Ok, just to clarify, the namespace name in the last example is "vmN.vmM", not "vmM" ? i.e. the namespaces are always hierarchical, and the security labels are identified by that hierarchy. If you enter vmM from the init namespace, for example, the security labels for it are distinct from the labels under vmN. On disk, you would have both: security.selinux.vmM security.selinux.vmN.vmM which are independent. Each of these instances would potentially inherit different labels, and have different provenance characteristics, so this seems necessary in any case. -- James Morris <james.l.mor...@oracle.com>
Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs
On Tue, 31 Oct 2017, Stephen Smalley wrote: > This btw would be a bit cleaner if we dropped the .ns. portion of the > name, such that we would have: > security.selinux # xattr name in the init namespace > security.selinux.vmN # xattr name in the vmN namespace > security.selinux.vmN.vmM # xattr name in the vmN.vmM namespace I used 'ns' to diffetentiate against other potential extensions of the xattr name. If that's not a concern, then yes it will be cleaner. Do we limit the number of nestings? -- James Morris <james.l.mor...@oracle.com>
Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs
On Mon, 30 Oct 2017, Stephen Smalley wrote: > Thanks, interesting approach. One drawback is that it doesn't presently > support any form of inheritance of labels from the parent namespace, so > files that are shared read-only from the init namespace will show up as > unlabeled in the child namespace until they are assigned the namespaced > attributes. This for example breaks running the selinux-testsuite with > this patch applied (unless perhaps you run restorecon -R / after > unsharing); otherwise just trying to invoke /usr/bin/runcon will fail > since it is unlabeled in the child. It seems like we should provide > some form of inheritance from the parent when there is no xattr for the > namespace itself. I was assuming that practical use of this would involve doing a filesystem relabel under the newly loaded policy, on first instantiation at least. We could try adding an selinuxfs node to specify default handling of unlabeled files in a child namespace, and write to that after mounting selinuxfs in that namespace. e.g. echo inherit > /sys/fs/selinux/parent_ns_labels or something. > > Another potential concern is that files created in a non-init namespace > are left completely unlabeled in the init namespace (or in any parent). > As long as access to unlabeled is tightly controlled, this might > not be a problem, but I'm not sure that's guaranteed by the refpolicy > or Fedora/RHEL policies. We might want to initialize an xattr at every > level of the namespace hierarchy when a new file is created based on > the process and parent directory labels and policy at that level. > Otherwise, we lose all provenance information for the file outside of > the namespace. Ok. > For example, suppose I want to leak information out of > my category set; I unshare and create files with the information, and > they appear in the init namespace with no categories. Nice :) -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH V3 1/2] security: Add a cred_getsecid hook
On Thu, 26 Oct 2017, Matthew Garrett wrote: > For IMA purposes, we want to be able to obtain the prepared secid in the > bprm structure before the credentials are committed. Add a cred_getsecid > hook that makes this possible. > > Signed-off-by: Matthew Garrett <mj...@google.com> > Acked-by: Paul Moore <p...@paul-moore.com> Acked-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH V3 2/2] IMA: Support using new creds in appraisal policy
On Thu, 26 Oct 2017, Matthew Garrett wrote: > The existing BPRM_CHECK functionality in IMA validates against the > credentials of the existing process, not any new credentials that the > child process may transition to. Add an additional CREDS_CHECK target > and refactor IMA to pass the appropriate creds structure. In > ima_bprm_check(), check with both the existing process credentials and > the credentials that will be committed when the new process is started. > This will not change behaviour unless the system policy is extended to > include CREDS_CHECK targets - BPRM_CHECK will continue to check the same > credentials that it did previously. > > Signed-off-by: Matthew Garrett <mj...@google.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [RFC PATCH 1/5] security: Add support for SCTP security hooks
On Tue, 17 Oct 2017, Richard Haines wrote: > The SCTP security hooks are explained in: > Documentation/security/LSM-sctp.txt > > Signed-off-by: Richard Haines <richard_c_hai...@btinternet.com> > --- > Documentation/security/LSM-sctp.txt | 212 > > include/linux/lsm_hooks.h | 37 +++ > include/linux/security.h| 27 + > security/security.c | 23 > 4 files changed, 299 insertions(+) > create mode 100644 Documentation/security/LSM-sctp.txt This looks ok from an LSM API pov, but note that I'm not an expert on SCTP. It would be good to see more review from networking folk. Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next v7 4/5] selinux: bpf: Add selinux check for eBPF syscall operations
On Wed, 18 Oct 2017, Chenbo Feng wrote: > From: Chenbo Feng <fe...@google.com> > > Implement the actual checks introduced to eBPF related syscalls. This > implementation use the security field inside bpf object to store a sid that > identify the bpf object. And when processes try to access the object, > selinux will check if processes have the right privileges. The creation > of eBPF object are also checked at the general bpf check hook and new > cmd introduced to eBPF domain can also be checked there. > > Signed-off-by: Chenbo Feng <fe...@google.com> > Acked-by: Alexei Starovoitov <a...@kernel.org> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next v7 3/5] security: bpf: Add LSM hooks for bpf object related syscall
On Wed, 18 Oct 2017, Chenbo Feng wrote: > From: Chenbo Feng <fe...@google.com> > > Introduce several LSM hooks for the syscalls that will allow the > userspace to access to eBPF object such as eBPF programs and eBPF maps. > The security check is aimed to enforce a per object security protection > for eBPF object so only processes with the right priviliges can > read/write to a specific map or use a specific eBPF program. Besides > that, a general security hook is added before the multiplexer of bpf > syscall to check the cmd and the attribute used for the command. The > actual security module can decide which command need to be checked and > how the cmd should be checked. > > Signed-off-by: Chenbo Feng <fe...@google.com> Acked-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next v6 0/5] bpf: security: New file mode and LSM hooks for eBPF object permission control
On Wed, 18 Oct 2017, David Miller wrote: > Series applied. I hadn't gotten to reviewing this patchset yet. Please wait for more acks/reviews from LSM folk for things touching security/, next time. -- James Morris <james.l.mor...@oracle.com>
[PATCH][RFC] selinuxns: mark init_selinux_ns as __ro_after_init
This is a patch against the SELinux namespace work. Mark the initial SELinux namespace pointer as __ro_after_init, to harden against malicious overwrite by an attacker. Signed-off-by: James Morris <james.l.mor...@oracle.com> --- security/selinux/hooks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 3daad14..98dbf57 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -97,7 +97,7 @@ #include "audit.h" #include "avc_ss.h" -struct selinux_ns *init_selinux_ns; +struct selinux_ns *init_selinux_ns __ro_after_init; /* SECMARK reference count */ static atomic_t selinux_secmark_refcount = ATOMIC_INIT(0); -- 1.8.3.1 -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next 2/4] security: bpf: Add LSM hooks for bpf object related syscall
On Wed, 4 Oct 2017, Chenbo Feng wrote:
> int bpf_map_new_fd(struct bpf_map *map, int flags)
> {
> + if (security_bpf_map(map, OPEN_FMODE(flags)))
> + return -EPERM;
> +
Don't hardcode -EPERM here, return the actual error from
security_bpf_map().
> + if (security_bpf_prog(prog))
> + return -EPERM;
> +
Same.
> + err = security_bpf(cmd, , size);
> + if (err)
> + return -EPERM;
Same.
- James
Re: [RFC 09/10] selinux: add a selinuxfs interface to unshare selinux namespace
On Mon, 9 Oct 2017, Stephen Smalley wrote: > On Oct 8, 2017 9:54 PM, "James Morris" <jmor...@namei.org> wrote: > > On Thu, 5 Oct 2017, Stephen Smalley wrote: > > > inet_socket test failures are expected due to running in a non-init > > network namespace; they don't work even without unsharing the selinux > > namespace. > > Do these results all look as expected? > > > No, that suggests that you either didn't insert the policy module allowing > access to unlabeled fds or you didn't run restorecon -R /dev before running > the tests. The only expected failures are the inet socket ones. > Looking better now -- I think it was the restorecon. -- James Morris <jmor...@namei.org>
Re: [RFC 03/10] selinux: move the AVC into the selinux namespace
On Mon, 2 Oct 2017, Stephen Smalley wrote: > Move the access vector cache (AVC) into the selinux namespace > structure and pass it explicitly to all AVC functions. The > AVC private state is encapsulated in a selinux_avc structure > that is allocated and freed by the AVC during selinux namespace > creation and destruction. > > This is necessary to support multiple selinux namespaces since > the AVC caches state (e.g. SIDs, policy sequence number) that > is maintained and provided by the security server on a per-namespace > basis. What about per-namespace AVC stats? At the moment, it seems that the stats for all AVCs are combined in the existing percpu stats, which could be confusing for someone trying to tune the host or a guest, as the hash stats & config are per-namespace. Also, a user likely wants to see only their own AVC stats generally. -- James Morris <jmor...@namei.org>
Re: [RFC 09/10] selinux: add a selinuxfs interface to unshare selinux namespace
On Thu, 5 Oct 2017, Stephen Smalley wrote: > inet_socket test failures are expected due to running in a non-init > network namespace; they don't work even without unsharing the selinux > namespace. Do these results all look as expected? Test Summary Report --- fdreceive/test (Wstat: 0 Tests: 3 Failed: 1) Failed test: 3 inherit/test (Wstat: 0 Tests: 3 Failed: 1) Failed test: 1 file/test (Wstat: 0 Tests: 16 Failed: 1) Failed test: 8 bounds/test(Wstat: 0 Tests: 24 Failed: 5) Failed tests: 3, 6, 12, 21, 23 mmap/test (Wstat: 0 Tests: 46 Failed: 2) Failed tests: 9, 13 inet_socket/test (Wstat: 3584 Tests: 33 Failed: 14) Failed tests: 1, 3, 5-6, 8, 16, 18, 20, 22, 25-26, 28 30, 32 Non-zero exit status: 14 overlay/test (Wstat: 3072 Tests: 121 Failed: 12) Failed tests: 1, 25, 27, 39-40, 57, 63, 87, 89, 98-99 116 Non-zero exit status: 12 Files=51, Tests=485, 28 wallclock secs ( 0.60 usr 0.13 sys + 2.67 cusr 3.76 csys = 7.16 CPU) Result: FAIL Failed 7/51 test programs. 36/485 subtests failed. -- James Morris <jmor...@namei.org>
Re: [RFC 05/10] selinux: support per-task/cred selinux namespace
On Fri, 6 Oct 2017, Serge E. Hallyn wrote: > Quoting James Morris (jmor...@namei.org): > > On Mon, 2 Oct 2017, Stephen Smalley wrote: > > > > > An alternative would be to hang the selinux namespace off of the > > > user namespace, which itself is associated with the cred. This > > > seems undesirable however since DAC and MAC are orthogonal, and > > > there appear to be real use cases where one will want to use selinux > > > namespaces without user namespaces and vice versa. > > > > Indeed, an Oracle use-case is for privileged containers and for this MAC > > must remain separate. > > Will that always be the case? Is that to allow (selinux-confined) device > administration from containers? It's to provide the user with a full OS experience generally. It's not necessarily the only use-case, though. -- James Morris <jmor...@namei.org>
Re: [RFC 05/10] selinux: support per-task/cred selinux namespace
On Mon, 2 Oct 2017, Stephen Smalley wrote: > An alternative would be to hang the selinux namespace off of the > user namespace, which itself is associated with the cred. This > seems undesirable however since DAC and MAC are orthogonal, and > there appear to be real use cases where one will want to use selinux > namespaces without user namespaces and vice versa. Indeed, an Oracle use-case is for privileged containers and for this MAC must remain separate. -- James Morris <jmor...@namei.org>
Re: [RFC 04/10] netns, selinux: create the selinux netlink socket per network namespace
On Mon, 2 Oct 2017, Stephen Smalley wrote: > This change presumes that one will always unshare the network namespace > when unsharing a new selinux namespace (the reverse is not required). > Otherwise, the same inconsistencies could arise between the notifications > and the relevant policy. At present, nothing enforces this guarantee > at the kernel level; it is left up to userspace (e.g. container runtimes). > It is an open question as to whether this is a good idea or whether > unsharing of the selinux namespace should automatically unshare the network > namespace. What about logging a kernel warning if just SELinux is unshared? I think we want to avoid surprising the user by unsharing things for them, and yes, it will be possible to mess your system up if you configure it badly. > However, keeping them separate is consistent with the handling > of the mount namespace currently, which also should be unshared so that > a private selinuxfs mount can be created. Right, and this will in practice always be automated and abstracted from an end user pov. -- James Morris <jmor...@namei.org>
Re: [PATCH] usb, signal, security: only pass the cred, not the secid, to kill_pid_info_as_cred and security_task_kill
On Fri, 8 Sep 2017, Paul Moore wrote: > Looks fine to me from a SELinux perspective. If Casey and John are > happy with this I can volunteer to pull it into the selinux/next tree > (once the merge window closes), otherwise if someone else wants to > merge this my ack is below. > As this impacts multiple LSMs, I'd prefer to take it via my tree. -- James Morris <jmor...@namei.org>
Re: [GIT PULL] SELinux patches for v4.14
On Thu, 31 Aug 2017, Paul Moore wrote: > Hi James, > > A relatively quiet period for SELinux, 11 patches with only two/three > having any substantive changes. These noteworthy changes include > another tweak to the NNP/nosuid handling, per-file labeling for > cgroups, and an object class fix for AF_UNIX/SOCK_RAW sockets; the > rest of the changes are minor tweaks or administrative updates > (Stephen's email update explains the file explosion in the diffstat). > Everything passes the selinux-testsuite and merged cleanly on top of > the linux-security/next branch from earlier today. > > Please apply. Merged, thanks. -- James Morris <jmor...@namei.org>
Re: [PATCH] MAINTAINERS: update the NetLabel and Labeled Networking information
On Thu, 10 Aug 2017, Paul Moore wrote: > On Thu, Aug 10, 2017 at 3:13 PM, Paul Moore <pmo...@redhat.com> wrote: > > From: Paul Moore <p...@paul-moore.com> > > > > Signed-off-by: Paul Moore <p...@paul-moore.com> > > --- > > MAINTAINERS | 24 ++-- > > 1 file changed, 14 insertions(+), 10 deletions(-) > > I'm planning on sending this up via the SELinux tree with some other > MAINTAINERS updates, consider this more of a FYI posting. Oops, already applied to -next. > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 65990909fe73..be25ebaaeec3 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9112,15 +9112,6 @@ F: net/*/netfilter/ > > F: net/netfilter/ > > F: net/bridge/br_netfilter*.c > > > > -NETLABEL > > -M: Paul Moore <p...@paul-moore.com> > > -W: http://netlabel.sf.net > > -L: net...@vger.kernel.org > > -S: Maintained > > -F: Documentation/netlabel/ > > -F: include/net/netlabel.h > > -F: net/netlabel/ > > - > > NETROM NETWORK LAYER > > M: Ralf Baechle <r...@linux-mips.org> > > L: linux-h...@vger.kernel.org > > @@ -9248,10 +9239,23 @@ F: net/ipv6/ > > F: include/net/ip* > > F: arch/x86/net/* > > > > -NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK) > > +NETWORKING [LABELED] (NetLabel, Labeled IPsec, SECMARK) > > M: Paul Moore <p...@paul-moore.com> > > +W: https://github.com/netlabel > > L: net...@vger.kernel.org > > +L: linux-security-mod...@vger.kernel.org > > S: Maintained > > +F: Documentation/netlabel/ > > +F: include/net/calipso.h > > +F: include/net/cipso_ipv4.h > > +F: include/net/netlabel.h > > +F: include/uapi/linux/netfilter/xt_SECMARK.h > > +F: include/uapi/linux/netfilter/xt_CONNSECMARK.h > > +F: net/netlabel/ > > +F: net/ipv4/cipso_ipv4.c > > +F: net/ipv6/calipso.c > > +F: net/netfilter/xt_CONNSECMARK.c > > +F: net/netfilter/xt_SECMARK.c > > > > NETWORKING [TLS] > > M: Ilya Lesokhin <il...@mellanox.com> > > -- James Morris <jmor...@namei.org>
Re: [PATCH] MAINTAINERS: update the NetLabel and Labeled Networking information
On Thu, 10 Aug 2017, Paul Moore wrote: > From: Paul Moore <p...@paul-moore.com> > > Signed-off-by: Paul Moore <p...@paul-moore.com> Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris <jmor...@namei.org>
Re: [GIT PULL] SELinux patches for v4.13
On Thu, 22 Jun 2017, Paul Moore wrote: > Hi James, > > While we're down to 21 patches for v4.13 (it was 31 for v4.12), the > diffstat jumps up tremendously with over 2k of line changes. Almost > all of these changes are the SELinux/IB work done by Daniel Jurgens; > some other noteworthy changes include a NFS v4.2 labeling fix, a new > file:map permission, and reporting of policy capabilities on policy > load. As usual, everything passes the selinux-testsuite and merges > cleanly with your current linux-security/next branch; please apply. > Thanks, pulled to -next. -- James Morris <jmor...@namei.org>
Re: [PATCH v7 0/9] SELinux support for Infiniband RDMA
On Fri, 19 May 2017, Dan Jurgens wrote: > From: Daniel Jurgens <dani...@mellanox.com> What kind of testing has this code had? It's relatively complex and as a security feature, it especially needs to be well-tested. -- James Morris <jmor...@namei.org>
Re: [PATCH v7 8/9] selinux: Add IB Port SMP access vector
On Fri, 19 May 2017, Dan Jurgens wrote: > From: Daniel Jurgens <dani...@mellanox.com> > > Add a type for Infiniband ports and an access vector for subnet > management packets. Implement the ib_port_smp hook to check that the > caller has permission to send and receive SMPs on the end port specified > by the device name and port. Add interface to query the SID for a IB > port, which walks the IB_PORT ocontexts to find an entry for the > given name and port. > > Signed-off-by: Daniel Jurgens <dani...@mellanox.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <jmor...@namei.org>
Re: [PATCH v7 7/9] selinux: Implement Infiniband PKey "Access" access vector
On Fri, 19 May 2017, Dan Jurgens wrote: > From: Daniel Jurgens <dani...@mellanox.com> > > Add a type and access vector for PKeys. Implement the ib_pkey_access > hook to check that the caller has permission to access the PKey on the > given subnet prefix. Add an interface to get the PKey SID. Walk the PKey > ocontexts to find an entry for the given subnet prefix and pkey. > > Signed-off-by: Daniel Jurgens <dani...@mellanox.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <jmor...@namei.org>
Re: [PATCH v7 6/9] selinux: Allocate and free infiniband security hooks
On Fri, 19 May 2017, Dan Jurgens wrote: > From: Daniel Jurgens <dani...@mellanox.com> > > Implement and attach hooks to allocate and free Infiniband object > security structures. > > Signed-off-by: Daniel Jurgens <dani...@mellanox.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <jmor...@namei.org>
Re: [PATCH v7 1/9] IB/core: IB cache enhancements to support Infiniband security
On Fri, 19 May 2017, Dan Jurgens wrote: > From: Daniel Jurgens <dani...@mellanox.com> > > Cache the subnet prefix and add a function to access it. Enforcing > security requires frequent queries of the subnet prefix and the pkeys in > the pkey table. > > Signed-off-by: Daniel Jurgens <dani...@mellanox.com> > Reviewed-by: Eli Cohen <e...@mellanox.com> > Reviewed-by: Leon Romanovsky <leo...@mellanox.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <jmor...@namei.org>
Re: [PATCH 3/3] selinux: expose policy SHA256 checksum via selinuxfs
On Wed, 26 Apr 2017, Stephen Smalley wrote: > > + return simple_read_from_buffer(buf, count, ppos, tmpbuf, > > length); > > +} > > Should we also include information about the hash used, in case it > changes in the future? > Good idea, yes. -- James Morris <jmor...@namei.org>
Re: [PATCH] selinux: Fix an uninitialized variable bug
On Mon, 3 Apr 2017, Paul Moore wrote: > James, I know you don't track SELinux development very closely so I'm > going to give you the benefit of the doubt and assume you haven't > already seen my responses to Markus in his 46 patch thread. If you > did follow the thread you would have noticed that I rejected several > of his patches as only adding noise/churn, and several more due to > personal preference; those that I did merge, I did review. I review > every patch that I merge, even the patches from Stephen. I did see the thread, and my email came across as critical of you, which was not my intention. I do certainly trust your skill and judgement. - James -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Fix an uninitialized variable bug
On Fri, 31 Mar 2017, Paul Moore wrote:
> On Fri, Mar 31, 2017 at 11:52 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
> > On Fri, 2017-03-31 at 18:21 +0300, Dan Carpenter wrote:
> >> We removed this initialization as a cleanup but it is probably
> >> required.
> >>
> >> The concern is that "nel" can be zero. I'm not an expert on SELinux
> >> code but I think it looks possible to write an SELinux policy which
> >> triggers this bug. GCC doesn't catch this, but my static checker
> >> does.
> >>
> >> Fixes: 9c312e79d6af ("selinux: Delete an unnecessary variable
> >> initialisation in range_read()")
> >> Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
> >
> > Nice catch, thanks!
> >
> > Acked-by: Stephen Smalley <s...@tycho.nsa.gov>
>
> Yes, indeed. Thanks Dan, I should have caught this when merging Markus'
> patch.
>
I'd like to reiterate that I generally don't want to accept cleanup
patches into the security tree from Markus (or indeed from others who
only do cleanup/whitespace work).
See https://lkml.org/lkml/2017/1/29/172, and please click through and read
Dan's comments.
All patches carry risks of introducing new bugs, and kernel "cleanup:
patches generally offer a pretty high cost/benefit ratio. If such patches
come from core developers of that code, or from kernel developers with
experience in *analyzing and fixing* bugs, that's very different.
Paul, please review all of these patches very carefully before sending
your pull request.
--
James Morris
<jmor...@namei.org>
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: isolate selinux_enforcing
On Thu, 9 Mar 2017, Eric W. Biederman wrote: > My expectation is that a container would run as essentially all one > label from a global perspective. > Keep in mind that a different classes of objects may have distinct labeling in SELinux. e.g. a process and a file typically have different labels (say, sshd_t vs. sshd_key_t). Also, I think you will want to have the global namespace always use the original security labels. If accessing an object from outside the container, the original global policy should always apply. Really, this needs to be an invariant property. I'd suggest implementing an orthogonal 2nd set of security labels which are only ever used within the container. > To implement this would require a revision on the selinux labels xattrs > so that they can be marked as being part of a container... But having > the labels look ordinary inside the container. > > We almost have a patch that implements something like that for the > capability xattr. It'll be interesting to see. -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: fix kernel BUG on prlimit(..., NULL, NULL)
On Tue, 28 Feb 2017, Stephen Smalley wrote: > > Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov> > --- Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next-queue -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] prlimit,security,selinux: add a security hook for prlimit
On Thu, 16 Feb 2017, Stephen Smalley wrote: > When SELinux was first added to the kernel, a process could only get > and set its own resource limits via getrlimit(2) and setrlimit(2), so no > MAC checks were required for those operations, and thus no security hooks > were defined for them. Later, SELinux introduced a hook for setlimit(2) > with a check if the hard limit was being changed in order to be able to > rely on the hard limit value as a safe reset point upon context > transitions. [...] Queued for 4.11 at git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next-queue -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [RFC] prlimit,security,selinux: add a security hook for prlimit
Looks good to me. -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [RFC v2 PATCH 1/2] security: introduce CONFIG_SECURITY_WRITABLE_HOOKS
On Tue, 14 Feb 2017, Tetsuo Handa wrote: > > diff --git a/security/Kconfig b/security/Kconfig > > index 118f454..f6f90c4 100644 > > --- a/security/Kconfig > > +++ b/security/Kconfig > > @@ -31,6 +31,11 @@ config SECURITY > > > > If you are unsure how to answer this question, answer N. > > > > +config SECURITY_WRITABLE_HOOKS > > + depends on SECURITY > > + bool > > + default n > > + > > This configuration option must not be set to N without big fat explanation > about implications of setting this option to N. It's not visible in the config menu, it's only there to support SELinux runtime disablement, otherwise it wouldn't even be an option. > > Honestly, I still don't like this option, regardless of whether SELinux > needs this option or not. > I agree, it would be better to just enable RO hardening without an option to disable it. -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
[RFC v2 PATCH 2/2] security: mark LSM hooks as __ro_after_init
Mark LSM hooks as __ro_after_init (via the __lsm_ro_after_init macro).
Signed-off-by: James Morris <james.l.mor...@oracle.com>
---
security/apparmor/lsm.c|2 +-
security/commoncap.c |2 +-
security/loadpin/loadpin.c |2 +-
security/security.c|2 +-
security/selinux/hooks.c |2 +-
security/smack/smack_lsm.c |2 +-
security/tomoyo/tomoyo.c |2 +-
security/yama/yama_lsm.c |2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 709eacd..e287b69 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -587,7 +587,7 @@ static int apparmor_task_setrlimit(struct task_struct *task,
return error;
}
-static struct security_hook_list apparmor_hooks[] = {
+static struct security_hook_list apparmor_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(ptrace_access_check, apparmor_ptrace_access_check),
LSM_HOOK_INIT(ptrace_traceme, apparmor_ptrace_traceme),
LSM_HOOK_INIT(capget, apparmor_capget),
diff --git a/security/commoncap.c b/security/commoncap.c
index 6d4d586..a9db18c 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1070,7 +1070,7 @@ int cap_mmap_file(struct file *file, unsigned long
reqprot,
#ifdef CONFIG_SECURITY
-struct security_hook_list capability_hooks[] = {
+struct security_hook_list capability_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(capable, cap_capable),
LSM_HOOK_INIT(settime, cap_settime),
LSM_HOOK_INIT(ptrace_access_check, cap_ptrace_access_check),
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 1d82eae..dbe6efd 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -174,7 +174,7 @@ static int loadpin_read_file(struct file *file, enum
kernel_read_file_id id)
return 0;
}
-static struct security_hook_list loadpin_hooks[] = {
+static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(sb_free_security, loadpin_sb_free_security),
LSM_HOOK_INIT(kernel_read_file, loadpin_read_file),
};
diff --git a/security/security.c b/security/security.c
index d0e07f2..75ed309 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1622,7 +1622,7 @@ int security_audit_rule_match(u32 secid, u32 field, u32
op, void *lsmrule,
}
#endif /* CONFIG_AUDIT */
-struct security_hook_heads security_hook_heads = {
+struct security_hook_heads security_hook_heads __lsm_ro_after_init = {
.binder_set_context_mgr =
LIST_HEAD_INIT(security_hook_heads.binder_set_context_mgr),
.binder_transaction =
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9bc12bc..b1a9916 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -6104,7 +6104,7 @@ static int selinux_key_getsecurity(struct key *key, char
**_buffer)
#endif
-static struct security_hook_list selinux_hooks[] = {
+static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(binder_set_context_mgr, selinux_binder_set_context_mgr),
LSM_HOOK_INIT(binder_transaction, selinux_binder_transaction),
LSM_HOOK_INIT(binder_transfer_binder, selinux_binder_transfer_binder),
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 60b4217..71e24d8 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4633,7 +4633,7 @@ static int smack_inode_getsecctx(struct inode *inode,
void **ctx, u32 *ctxlen)
return 0;
}
-static struct security_hook_list smack_hooks[] = {
+static struct security_hook_list smack_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(ptrace_access_check, smack_ptrace_access_check),
LSM_HOOK_INIT(ptrace_traceme, smack_ptrace_traceme),
LSM_HOOK_INIT(syslog, smack_syslog),
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index edc52d6..b5fb930 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -496,7 +496,7 @@ static int tomoyo_socket_sendmsg(struct socket *sock,
struct msghdr *msg,
* tomoyo_security_ops is a "struct security_operations" which is used for
* registering TOMOYO.
*/
-static struct security_hook_list tomoyo_hooks[] = {
+static struct security_hook_list tomoyo_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(cred_alloc_blank, tomoyo_cred_alloc_blank),
LSM_HOOK_INIT(cred_prepare, tomoyo_cred_prepare),
LSM_HOOK_INIT(cred_transfer, tomoyo_cred_transfer),
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 88271a3..8298e09 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -428,7 +428,7 @@ int yama_ptrace_traceme(struct task_struct *parent)
return rc;
}
-static struct security_hook_list yama_hooks[] = {
+static struct security_hook_list yama_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(ptrace_access_check, yama_ptr
[RFC v2 PATCH 2/2] security: mark LSM hooks as __ro_after_init
Mark all of the registration hooks as __ro_after_init (via the
__lsm_ro_after_init macro).
Signed-off-by: James Morris <james.l.mor...@oracle.com>
---
security/apparmor/lsm.c|2 +-
security/commoncap.c |2 +-
security/loadpin/loadpin.c |2 +-
security/security.c|2 +-
security/selinux/hooks.c |2 +-
security/smack/smack_lsm.c |2 +-
security/tomoyo/tomoyo.c |2 +-
security/yama/yama_lsm.c |2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 709eacd..e287b69 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -587,7 +587,7 @@ static int apparmor_task_setrlimit(struct task_struct *task,
return error;
}
-static struct security_hook_list apparmor_hooks[] = {
+static struct security_hook_list apparmor_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(ptrace_access_check, apparmor_ptrace_access_check),
LSM_HOOK_INIT(ptrace_traceme, apparmor_ptrace_traceme),
LSM_HOOK_INIT(capget, apparmor_capget),
diff --git a/security/commoncap.c b/security/commoncap.c
index 6d4d586..a9db18c 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1070,7 +1070,7 @@ int cap_mmap_file(struct file *file, unsigned long
reqprot,
#ifdef CONFIG_SECURITY
-struct security_hook_list capability_hooks[] = {
+struct security_hook_list capability_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(capable, cap_capable),
LSM_HOOK_INIT(settime, cap_settime),
LSM_HOOK_INIT(ptrace_access_check, cap_ptrace_access_check),
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 1d82eae..dbe6efd 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -174,7 +174,7 @@ static int loadpin_read_file(struct file *file, enum
kernel_read_file_id id)
return 0;
}
-static struct security_hook_list loadpin_hooks[] = {
+static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(sb_free_security, loadpin_sb_free_security),
LSM_HOOK_INIT(kernel_read_file, loadpin_read_file),
};
diff --git a/security/security.c b/security/security.c
index d0e07f2..75ed309 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1622,7 +1622,7 @@ int security_audit_rule_match(u32 secid, u32 field, u32
op, void *lsmrule,
}
#endif /* CONFIG_AUDIT */
-struct security_hook_heads security_hook_heads = {
+struct security_hook_heads security_hook_heads __lsm_ro_after_init = {
.binder_set_context_mgr =
LIST_HEAD_INIT(security_hook_heads.binder_set_context_mgr),
.binder_transaction =
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9bc12bc..b1a9916 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -6104,7 +6104,7 @@ static int selinux_key_getsecurity(struct key *key, char
**_buffer)
#endif
-static struct security_hook_list selinux_hooks[] = {
+static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(binder_set_context_mgr, selinux_binder_set_context_mgr),
LSM_HOOK_INIT(binder_transaction, selinux_binder_transaction),
LSM_HOOK_INIT(binder_transfer_binder, selinux_binder_transfer_binder),
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 60b4217..71e24d8 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4633,7 +4633,7 @@ static int smack_inode_getsecctx(struct inode *inode,
void **ctx, u32 *ctxlen)
return 0;
}
-static struct security_hook_list smack_hooks[] = {
+static struct security_hook_list smack_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(ptrace_access_check, smack_ptrace_access_check),
LSM_HOOK_INIT(ptrace_traceme, smack_ptrace_traceme),
LSM_HOOK_INIT(syslog, smack_syslog),
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index edc52d6..b5fb930 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -496,7 +496,7 @@ static int tomoyo_socket_sendmsg(struct socket *sock,
struct msghdr *msg,
* tomoyo_security_ops is a "struct security_operations" which is used for
* registering TOMOYO.
*/
-static struct security_hook_list tomoyo_hooks[] = {
+static struct security_hook_list tomoyo_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(cred_alloc_blank, tomoyo_cred_alloc_blank),
LSM_HOOK_INIT(cred_prepare, tomoyo_cred_prepare),
LSM_HOOK_INIT(cred_transfer, tomoyo_cred_transfer),
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 88271a3..8298e09 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -428,7 +428,7 @@ int yama_ptrace_traceme(struct task_struct *parent)
return rc;
}
-static struct security_hook_list yama_hooks[] = {
+static struct security_hook_list yama_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(ptr
[RFC v2 PATCH 1/2] security: introduce CONFIG_SECURITY_WRITABLE_HOOKS
Subsequent patches will add RO hardening to LSM hooks, however, SELinux still needs to be able to perform runtime disablement after init to handle architectures where init-time disablement via boot parameters is not feasible. Introduce a new kernel configuration parameter CONFIG_SECURITY_WRITABLE_HOOKS, and a helper macro __lsm_ro_after_init, to handle this case. Signed-off-by: James Morris <james.l.mor...@oracle.com> --- include/linux/lsm_hooks.h |7 +++ security/Kconfig |5 + security/selinux/Kconfig |6 ++ 3 files changed, 18 insertions(+), 0 deletions(-) diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index e29d4c6..c4b149f 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -1908,6 +1908,13 @@ static inline void security_delete_hooks(struct security_hook_list *hooks, } #endif /* CONFIG_SECURITY_SELINUX_DISABLE */ +/* Currently required to handle SELinux runtime hook disable. */ +#ifdef CONFIG_SECURITY_WRITABLE_HOOKS +#define __lsm_ro_after_init +#else +#define __lsm_ro_after_init__ro_after_init +#endif /* CONFIG_SECURITY_WRITABLE_HOOKS */ + extern int __init security_module_enable(const char *module); extern void __init capability_add_hooks(void); #ifdef CONFIG_SECURITY_YAMA diff --git a/security/Kconfig b/security/Kconfig index 118f454..f6f90c4 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -31,6 +31,11 @@ config SECURITY If you are unsure how to answer this question, answer N. +config SECURITY_WRITABLE_HOOKS + depends on SECURITY + bool + default n + config SECURITYFS bool "Enable the securityfs filesystem" help diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig index ea7e3ef..8af7a69 100644 --- a/security/selinux/Kconfig +++ b/security/selinux/Kconfig @@ -40,6 +40,7 @@ config SECURITY_SELINUX_BOOTPARAM_VALUE config SECURITY_SELINUX_DISABLE bool "NSA SELinux runtime disable" depends on SECURITY_SELINUX + select SECURITY_WRITABLE_HOOKS default n help This option enables writing to a selinuxfs node 'disable', which @@ -50,6 +51,11 @@ config SECURITY_SELINUX_DISABLE portability across platforms where boot parameters are difficult to employ. + NOTE: selecting this option will disable the '__ro_after_init' + kernel hardening feature for security hooks. Please consider + using the selinux=0 boot parameter instead of enabling this + option. + If you are unsure how to answer this question, answer N. config SECURITY_SELINUX_DEVELOP -- 1.7.1 ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
[RFC v2 PATCH 0/2] security: mark LSM hooks with __ro_after_init
Updated and simplified down to two patches. Following feedback from the list, I've added a new config option to handle the case where SELinux still needs to disable its hooks at runtime (and thus the hooks must be writable in that case). I've dropped the Netfilter hooks patch as I realized that the hook ops list structures could be modified after init by the core NF code. The SELinux Netlink message patch has been merged, and Mimi is reviewing the IMA default policy patch (it's not affected by LSM hook requirements and can be merged separately). --- James Morris (2): security: introduce CONFIG_SECURITY_WRITABLE_HOOKS security: mark LSM hooks as __ro_after_init include/linux/lsm_hooks.h |7 +++ security/Kconfig |5 + security/apparmor/lsm.c|2 +- security/commoncap.c |2 +- security/loadpin/loadpin.c |2 +- security/security.c|2 +- security/selinux/Kconfig |6 ++ security/selinux/hooks.c |2 +- security/smack/smack_lsm.c |2 +- security/tomoyo/tomoyo.c |2 +- security/yama/yama_lsm.c |2 +- 11 files changed, 26 insertions(+), 8 deletions(-) ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [GIT PULL] SELinux patches for 4.11
On Thu, 9 Feb 2017, Paul Moore wrote: > Hi James, > > Eleven SELinux patches for v4.11 with a mix of cleanups, fixes, and > new functionality (object classes and filesystem support). Everything > passes the selinux-testsuite and applied cleanly to the > linux-security/next branch as of a few minutes ago; please apply. Pulled, thanks! -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v4 17/21] capabilities: Allow privileged user in s_user_ns to set security.* xattrs
On Tue, 26 Apr 2016, Seth Forshee wrote: > A privileged user in s_user_ns will generally have the ability to > manipulate the backing store and insert security.* xattrs into > the filesystem directly. Therefore the kernel must be prepared to > handle these xattrs from unprivileged mounts, and it makes little > sense for commoncap to prevent writing these xattrs to the > filesystem. The capability and LSM code have already been updated > to appropriately handle xattrs from unprivileged mounts, so it > is safe to loosen this restriction on setting xattrs. > > The exception to this logic is that writing xattrs to a mounted > filesystem may also cause the LSM inode_post_setxattr or > inode_setsecurity callbacks to be invoked. SELinux will deny the > xattr update by virtue of applying mountpoint labeling to > unprivileged userns mounts, and Smack will deny the writes for > any user without global CAP_MAC_ADMIN, so loosening the > capability check in commoncap is safe in this respect as well. > > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> > Acked-by: Serge Hallyn <serge.hal...@canonical.com> Acked-by: James Morris <james.l.mor...@oracle.com> -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH net-next] security: drop the unused hook skb_owned_by
On Fri, 8 Apr 2016, Paolo Abeni wrote:
> The skb_owned_by hook was added with the commit ca10b9e9a8ca
> ("selinux: add a skb_owned_by() hook") and later removed
> when said commit was reverted.
>
> Later on, when switching to list of hooks, a field named
> 'skb_owned_by' was included into the security_hook_head struct,
> but without any users nor caller.
>
> This commit removes the said left-over field.
>
> Fixes: b1d9e6b0646d ("LSM: Switch to lists of hooks")
> Signed-off-by: Paolo Abeni <pab...@redhat.com>
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
--
James Morris
<jmor...@namei.org>
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [RFC PATCH 0/7] SELinux support for Infiniband RDMA
On Tue, 5 Apr 2016, Daniel Jurgens wrote: > On 4/4/2016 8:13 PM, James Morris wrote: > > On Tue, 5 Apr 2016, Dan Jurgens wrote: > > > >> From: Daniel Jurgens <dani...@mellanox.com> > >> > >> Currently there is no way to provide granular access control to an > >> Infiniband > >> fabric. By providing an ability to restrict user access to specific > >> virtual > >> subfabrics administrators can limit access to bandwidth and isolate users > >> on > >> the fabric. > > > > Where are the LSM hooks placed? > > > > > > > The LSM hooks are defined in patch 1/7 of this series. There are 4 that > will be called from ib_core, and one that's implemented by ib_core to be > called by a security module if the policy or enforcement setting change > (infiniband_flush). That call from SELinux is added in patch 3/7 of > this series. Can you post the ib_core patches, too? -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [GIT PULL] SELinux fixes for 4.5 (#1)
On Mon, 11 Jan 2016, Paul Moore wrote: > Hi James, > > A single small patch to address a performance regression in the SELinux pull > request from late December. Please apply. > > -Paul > > --- > The following changes since commit 76319946f321e30872dd72af7de867cb26e7a373: > > selinux: rate-limit netlink message warnings in selinux_nlmsg_perm() >(2015-12-24 11:09:41 -0500) > > are available in the git repository at: > > git://git.infradead.org/users/pcmoore/selinux upstream > > for you to fetch changes up to b197367ed1ba81b0d26f7e7f76f61731ac6e5842: > > selinux: Inode label revalidation performance fix >(2016-01-08 16:24:27 -0500) > > > Andreas Gruenbacher (1): > selinux: Inode label revalidation performance fix > > security/selinux/hooks.c | 10 ++---- > 1 file changed, 2 insertions(+), 8 deletions(-) > Pulled, thanks. -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH v3 0/7] User namespace mount updates
On Wed, 18 Nov 2015, Richard Weinberger wrote: > On Wed, Nov 18, 2015 at 4:13 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > > On Wed, Nov 18, 2015 at 09:05:12AM -0600, Seth Forshee wrote: > > > >> Yes, the host admin. I'm not talking about trusting the admin inside the > >> container at all. > > > > Then why not have the same host admin just plain mount it when setting the > > container up and be done with that? From the host namespace, before > > spawning > > the docker instance or whatever framework you are using. IDGI... > > Because hosting companies sell containers as "full virtual machines" > and customers expect to be able mount stuff like disk images they upload. I don't think this is a valid reason for merging functionality into the kernel. -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [GIT PULL] SELinux patches for 4.4
On Wed, 21 Oct 2015, Paul Moore wrote: > Hi James, > > Nine SELinux patches in total for v4.4, although six of those patches are > either trivial, minor cleanups, or both. The remaining three patches aren't > too bad: one changes the CHECKREQPROT default to check the actual memory > protections, one stops us from checking file:open on ftruncate() calls, and > one converts the file_security_struct over to kmem_cache. > > All pass the SELinux testsuite and should apply cleanly on top of your next > branch. > Pulled, thanks. -- James Morris <jmor...@namei.org> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
