On Mon, 2006-04-03 at 18:39 +0300, Török Edwin wrote:
> I am not trying to reinvent SELinux. But I do not know how to accomplish what
> I want with SELinux.
>
> Here it is what I want:
> - have security labels applied to sockets based on their owners (ok, I guess
> SELinux does this by default)
Yes, if owner == creator.
> - the security labels of processes be assigned based on their executable's
> inode+mountpoint.
Not sure what you mean by inode+mountpoint here. SELinux already allows
you to define a domain transition for the process based on the caller's
domain and the type assigned to the executable file via inode extended
attribute.
> Is there a way to do auto-labeling with SELinux? I mean having a security
> context applied based on the inode, without me having to run 'make relabel',
> setfiles, and so on....
Attributes have to be bound to the actual objects, which means that
something has to set those attributes. This is no different than normal
Linux DAC attributes like file owner/group/mode (aside from the need to
use extended attributes for storage). Some package managers have
already been extended to support setting SELinux attributes when files
are installed, like rpm in Fedora, dpkg in Debian unstable, portage in
Hardened Gentoo. install(1) in Fedora also is patched to apply the
proper context for installation of files without using the package
manager. restorecon can be selectively applied to specific files to
restore their labels to the initial values specified in the
configuration.
> Let's say I compile&install a program. Can it have a security label
> auto(magically) applied, based on the inode of its executable? (without
> recompiling, & reloading the policy)
>
> (From my very limited understanding of SELinux, this would mean creating a
> context for each executable, that is altering the policy, if each executable
> needs to have a separate context. Is it possible to dinamically generate the
> context at runtime? Is it possible to integrate my autolabel.c with SELinux?)
If you truly need to distinguish each such program, then yes, they would
need separate contexts, although you likely can organize them into
equivalence classes. You could generate a policy module in userspace
and feed it to semodule to be linked into the base policy and loaded,
although the details are not entirely clear as to what you would need to
put into the policy module (e.g. you seem to just want to define the
domain and type and then make the domain identical to the caller's
domain since you aren't trying to restrict it any further, just use it
for labeling purposes).
> It doesn't have to have a security label applied by its inode, but that is
> unique, I don't know how secure would it be to identify processes by path...
It isn't. Path-based access control considered harmful.
> If the above is possible, could you please provide pointers to documentation?
>
> How can I implement auto-labeling with SELinux? (is there a possibility to
> write some sort of plugins that provide this functionality?)
>
> To sum up, I wrote my LSM stuff because I didn't know how to use SELinux to
> accomplish what I wanted.
> If it can be done with SELinux easily, I'm happy to switch to that. (easy from
> the end-user's perspective, using fireflier for example. it doesn't matter
> how much work it would imply to make fireflier handle the stuff "behind the
> scenes")
You aren't likely to get much review of your actual LSM without breaking
it up into manageable chunks and posting with patches inline for review
to [email protected].
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
