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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 12 Dec 2007 11:37:32 -0800 (PST)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	David Howells <dhowells@...hat.com>,
	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	dhowells@...hat.com, casey@...aufler-ca.com,
	Karl MacMillan <kmacmill@...hat.com>, viro@....linux.org.uk,
	hch@...radead.org, Trond.Myklebust@...app.com,
	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]


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

> Stephen Smalley <sds@...ho.nsa.gov> wrote:
> 
> > That sounds workable, although I think he will want a more specific hook
> > than security_secctx_to_secid(), or possibly a second hook call, that
> > would not only validate the context but authorize the use of it by the
> > cachefilesd process.  And then the security_task_kernel_act_as() hook
> > just takes the secid as input rather than the task struct of the daemon,
> > and applies it.  At that point, nfsd can use the same mechanism for
> > setting the acting SID based on the client process after doing its own
> > authorization.
> 
> I thought using secids was verboten as it made things too specific.

I have argued that in the past. I'm reasonably convinced that I have
lost that argument at least for the immediate future as audit, usb,
and networking are all dependent on them. I can't image an LSM that
manages to avoid them, at least for the short term. If secid's are
ever expundged from the kernel cachefiles will require reeducation,
but that will be a minor effort.

> Have you example code for the security hook you mention?  I'm not sure I
> understand why security_secctx_to_secid() is not sufficient.
> 
> Or is it that I need something that takes a secctx, converts it to a secid
> and
> authorises its use all in one go?
> If it's this, why can't that be rolles
> into
> security_task_kernel_act_as()?  That sets up a task_security struct which is
> then switched in and out without consultation of the LSM.

It would seem to me that security_secctx_to_secid() ought to suffice
if the application code was written correctly. Be aware that factors
outside the LSM may be important, too. As Stephen points out elsewhere,
Smack will require you have particular capabilities (CAP_MAC_OVERRIDE,
CAP_MAC_ADMIN) while a DAC LSM may require CAP_DAC_OVERRIDE. SELinux
is likely to be the odd duck in this pond in that it does not use the
capability mechanism in the way Nature intends it to be, opting to
treat "privilege" with a completely different model.


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