[RFC] packet/socket owner match (fireflier) using skfilter

[RFC] packet/socket owner match (fireflier) using skfilter

[Török Edwin]

Fireflier aims at providing per application filtering. That is allowing to 
create rules like: allow apache to listen on port 80 (and only apache, nobody 
else).

A couple of days ago fireflier security module + iptables fireflier match 
module started to work [8].

Before continuing the work on it, I ask for your advice, and comments on what 
I've done so far.
I have marked with [!] the issues that are currently the most important.

0. Getting the patch/code
---------------------
All code/patches is for kernel 2.6.16.1, and iptables 1.3.5

I didn't include the patch inline, since it is quite long (1800+ lines , 
~100k). So I uploaded them here:
http://edwintorok.googlepages.com/fireflier_kernel.html

James Morris's patches [5] didn't apply cleanly to 2.6.16.1, so I had to 
modify them a bit, I have uploaded the actual patches applied
to the kernel, and iptables. (I might have made mistakes in "porting" the 
skfilter patches to 2.6.16, please point them out to me)

For the impatient, a direct link to the download:
http://edwintorok.googlepages.com/fireflier_modules.zip
http://edwintorok.googlepages.com/skfilter_patches.zip

1. Background
-----------------------
The initial approach [1] as pointed out by several ([2],[3])  people was 
fundamentally wrong.

AFAIK there is currently work being done to solve this using SELinux [4], but 
I'd like to have 'per application filtering' even without SELinux, so I
looked at James Morris and Patrick McHardy's skfilter patches [5].

So my idea was, that we use James Morris's patches, but instead of using the 
selinux security context, we use a security context based on the process's 
(its executable's) inode+mountpoint. For this we need some sort of 
auto-labeling. The LSM hooks provide just enough hooks in the right places to 
support this.
I have also written an iptables match target (and appropriate userspace 
libipt_...) based on ipt_owner.c, that matches based on the labels (SIDs) 
provided by fireflier LSM.

A detailed description of why, and how I've done this can be found on the 
wiki[6].

This code is currently working, see the tests I have done:[8]

2. Goals of fireflier LSM module
----------------------------------------
    * auto label each process with its executable's inode+mountpoint, i.e. a 
process's security context = SID based on {mountpoint+inode of its 
executable}
    * auto label each file a process has access to. If multiple processes have 
access to the same file, then create a group SID, containing all the SIDs of 
processes having access it. 
    * If multiple processes have access to the same file, but were launched 
from the same executable, then don't label with group SID (like 10 apache 
processes accessing the same socket: the socket will get the SID of apache)
    * it won't deny any operation, it just labels
    * it is not intended to be used when selinux=1 enabled at boot. If selinux 
is enabled then selinux should be used to provide the security context, and 
not fireflier 

3. Issues with fireflier LSM
-----------------------------------------

3.1 Duplicate code
---------------------
I needed a SID <-> context mapping, and I've seen that SELinux already has 
such a data structure in sidtab.c
There was no way to use that as is, since it had no exported symbols, and 
besides my context structure was different from an SELinux context,
so I copied sidtab.c to fireflier LSM. The problem is that a bug gets fixed in 
sidtab.c, ... it doesn't in fireflier LSM.
How can I use the functionality provided by sidtab.c in my LSM without 
duplicating the code?
I have thought of this solution, but I'm not sure if it is the best:
* create a patch between the selinux sidtab, and fireflier sidtab
* every time sidtab.c is changed in the kernel copy it to fireflier
* apply the patch

Also hooks.c is based on hooks.c from SELinux.

3.2 Capability module doesn't support stacking [!]
-----------------------------------------------
I have to boot with capability.disable=1 in order to be able to load 
fireflier. Otherwise it fails to register (it can't register neither as 
primary, neither as secondary LSM). Can stacking be added to the capability 
module? 

3.3 Fireflier LSM loaded as module [!]
-----------------------------------
Currently fireflier LSM is loaded as a module, and not compiled in the kernel. 
Are there any security issues that might arise from this?
(such as [9])

3.4 Performance
------------------
The SID->context lookup uses hashtable, ok.
But  context->SID lookup uses linear search (through the hash-table), can this 
be improved?
Using another hash-table, that based on the hash of a context maps to a SID 
would solve this, but it needs additional memory.

As far as autolabel.c is concerned I need to do the following: label only 
sockets, and not all inodes, for this I need to provide hook for 
socket_create, and label inodes only there?

3.5 Testing
------------
I will have to implement auto-test, that test the labels are properly applied. 
For this purpose I have created a debugging mode, where I create files
in debugfs (it currently only creates them, that is it leaks memory, I'll fix 
this later).
Is there a recommended way to do such tests? How is SELinux being tested?



4. Issues with fireflier iptables match
----------------------------------------
This is what it can currently handle:
iptables -t skfilter -A SOCKET -m fireflier_match --inode-owner 
81949 --dev-owner /dev/root -j ACCEPT

4.1 No group matching yet [!]
--------------------------
It currently matches against individual SIDs only, and can't match against 
groups. (in case a socket has a group SID, it won't be matched by the rule)
I have thought of several [7] solutions, but I am not sure which one is the 
Right Way to do it. 
IMHO solution II ([7]) would be the appropriate one:
* if a packet arrives on a socket having a group SID, and the rule tells to 
match on a SID contained in that group, then:
   * mark the packet, that it has been matched by the SID (of this rule)
   * if the packet has been marked that is has been matched by all SIDs in the 
group, then the packet is allowed to pass (i.e. matched by the rule)

The problems are:
* Can I do packet marking outside the mangle table? (in the skfilter table)?
* What would the performance penalty be to mark packets?
* How much memory would this need?
* How do I do the actual packet marking?

4.2 Duplicate code
-------------------------

I haven't included the fireflier match inside ipt_owner.c, because I wanted it 
to be installed as easy as possible, and this means, that
both the LSM module, and math module are compiled outside of the kernel tree 
currently.

What would I need to do in order to have this merged in the kernel tree? What 
conditions does the module (patch) have to meet?
Should I create a patch that can be applied with patch-o-matic-ng?

4.3 Performance benchmark
---------------------------
What is recommended way to profile an iptables match module? What tests do you 
suggest?

4.4. Testing
--------------------
I'd like to implement auto-tests for the iptables module too.
Besides testing saving/loading the rules, I'd like to test if it actually 
works. I am thinking of doing this:
* start up 3 processes:
  - program A that forks itself, and listens on a non-shared socket (lets say 
port 80, apache)
  - program B, and C share a socket with the 3rd one (lets say port 25, 
postfix)
  - program D that doesn't fork (and listens on port 22, sshd)
* create rules that match on different scenarios:
  - dst port 80, apache inode => this has to match
  - dst port 25, inode of B => this mustn't match
  - dst port 25, inode of C => this should match (if using solution II[7])
  - dst port 22, inode of B => mustn't match
  - dst port 22, inode of D => has to match
and so on
Is there a "standard" way to run such tests?

4.5 IPV6
---------
Currently the fireflier module is IPv4 only, is there anything I have to look 
out for when I "port" it to ipv6?
Should I do this now? I see that ip|ip6|arp_tables are being moved to 
x_tables, does it mean that ipv4 and ipv6 are going to be "unified"?
Do I have to do anything to support x_tables?

5. Use of the kernel API [!]
----------------------

Are the functions I used in the 2 modules part of a stable kernel API? Did I 
use functions/structures that a driver isn't supposed to use?
Are there any plans to remove a feature I used in my modules?

P.S.: there are hard coded path in some files, that is going to be fixed in a 
later version

I am waiting for your advice/suggestions/comments.

(note: although some of the pages on the wiki were last updated on April the 
1st, they are not an April's fool joke)

Thanks in advance,
Edwin

[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0602.2/0701.html
[2] http://www.uwsg.iu.edu/hypermail/linux/kernel/0602.2/0709.html
[3] http://www.uwsg.iu.edu/hypermail/linux/kernel/0602.2/0725.html
[4] http://www.uwsg.iu.edu/hypermail/linux/kernel/0602.2/0792.html
[5] http://www.uwsg.iu.edu/hypermail/linux/kernel/0602.2/1310.html
[6] http://fireflier.isgeeky.com/wiki/Kernel_module
[7]http://fireflier.isgeeky.com/wiki/Kernel_module#Multiple_programs_accessing_a_socket
[8] http://fireflier.isgeeky.com/wiki/Ipt_fireflier_test
[9]http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/0390.html

Re: [RFC] packet/socket owner match (fireflier) using skfilter

[James Morris]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 290 bytes --]

On Sun, 2 Apr 2006, Török Edwin wrote:

> Before continuing the work on it, I ask for your advice, and comments on what 
> I've done so far.

I would suggest dropping your LSM stuff and just using SELinux.  It's 
crazy to try and reinvent it.



- James
-- 
James Morris
<jmorris@namei.org>

Re: [RFC] packet/socket owner match (fireflier) using skfilter

[Török Edwin]

On Monday 03 April 2006 18:18, James Morris wrote:
> On Sun, 2 Apr 2006, Török Edwin wrote:
> > Before continuing the work on it, I ask for your advice, and comments on
> > what I've done so far.
>
> I would suggest dropping your LSM stuff and just using SELinux.  It's
> crazy to try and reinvent it.
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)

- the security labels of processes be assigned based on their executable's 
inode+mountpoint.
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....
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?)

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...

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")

Thanks in advance,
Edwin

Re: [RFC] packet/socket owner match (fireflier) using skfilter

[Stephen Smalley]

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 linux-security-module@vger.kernel.org.

-- 
Stephen Smalley
National Security Agency

Re: [RFC] packet/socket owner match (fireflier) using skfilter

[Török Edwin]

On Wednesday 05 April 2006 18:06, Stephen Smalley wrote:
> On Mon, 2006-04-03 at 18:39 +0300, Török Edwin wrote:
> > - the security labels of processes be assigned based on their
> > executable's inode+mountpoint.
>
> Not sure what you mean by inode+mountpoint here. 
I meant security labels generated automatically based on the inode and 
mountpoint of executable, without having to apply extended attributes to 
them.
> > 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.
Obviously.
> This is no different than normal 
> Linux DAC attributes like file owner/group/mode (aside from the need to
> use extended attributes for storage).
I don't want to store the attribute.
>
> > (From my very limited understanding of SELinux, this would mean creating
> > a context for each executable, 
>
> 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. 
I thought of equivalence classes like: class_ports_all_access, 
class_port_80_access, class_port_25_access, etc. But can a program have 
multiple classess associated? (or multiple contexts?) If not, I should also 
create some sort of group classes (class_port_80_443: 
class_port_80,class_port_443)
> 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).
Thanks, this is very usefull.I didn't know about the modular policy support. 
It is great, as it will allow easier installation :)
Let me see if I got it right:
- I can generate a policy from userspace
- compile it into a module package
- load that using semodule
- generating the policy will be indepedent of the base policy
- the user can change the base policy, and the my policy module will still 
work (without recompiling it)


I am not sure what should be in the policy either, I thought of this:
- when a new rule is added to fireflier the policy module is updated
- domain&type is generated, that is unique to each program
- "labels" the program with the generated domain&type (is this possible 
without storing the context on disk?)
- "labels" each socket created by the program with the program's label
- when a domain transition occurs, all sockets that are open, are relabeled, 
to show that 2 domains have access to it (relabeled with an auto-generated 
context, that is some sort of a group, i.e. I can later retrieve what the 
members of that group was)
- the policy doesn't have to restrict anything, only label

Since I have already written a LSM that accomplishes what I want, can 
somebody "guide" me how to "convert" the LSM to an SELinux policy? I'd 
appreciate if you can give me ideas how to implement the parts that would 
be "translated" to a "non-standard"(unusual, features not used in the 
reference policy,...) policy file (are there such parts?).

To get started I have the following  (fundamental) question: can a program 
have multiple contexts? If not, how I can let the user use whatever context 
he wants for the program, and still apply my label to it?

If I get an answer to that question above, I'll start learning, and 
experimenting, and come back later with more questions.

If such a policy module is written, can that be used as base policy, if the 
user doesn't (yet) have a base policy? For example he boots with selinux=1, 
but he didn't set up his policy....
>
> > 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.
Agreed. The fireflier LSM I've written does filtering based on inode.
Fireflier currently does (userspace) filtering based on the path, but I'll 
change that, and put the inode in the rule file too. And in case the path no 
longer matches the inode, the user is asked if he wants to update the 
rules.... but this is the userspace part of it.
> 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 linux-security-module@vger.kernel.org.
I will do that, I'll post them as replies to this mail. Thanks for pointing me 
to the proper list.

The fireflier LSM will be used only if the user has selinux disabled. This is 
my plan:

- if selinux is enabled: use the userspace policy module generator (not yet 
written)
- if selinux is disabled: use fireflier LSM (already written)

Please note that I am not trying to reinvent SELinux, I just want to provide a 
way of doing this application filtering, when the user has selinux disabled.

The actual packet filtering will be done:
 - userspace (using nf_queue, and getxattr)
 - using skfilter patches (as soon as they are merged in mainline)


In the end I want to thank all of you for helping me develop fireflier.

Cheers,
Edwin

[RFC][PATCH 0/7] fireflier LSM for labeling sockets based on its creator (owner)

[Török Edwin]

Hi,

The purpose of the fireflier LSM is to "label" each socket with a context, 
where the context is a (list of) the program(s) that has/have access to it.

I've written fireflier LSM to allow filtering packets "per application". It is 
meant to be used only when SELinux is not available (not available/disabled 
at boot). For more details, see the initial discussion [1]

Summary of how fireflier LSM works:
- each program is associated a sid, depending on its mountpoint+inode, i.e. 2 
processes launched from the same program have the same sid
- each socket created by a processis labeled with the process's sid
- if 2 or more programs have access to the socket, it is labeled with a "group 
sid". A group sid contains a list of the sids of programs having access
- userspace, or iptables module can match packets on this "fireflier context"

As I stated in my previous mail, I intend to write a userspace policy module 
generator, that is to be used when selinux is enabled.
When it is disabled, then only would the fireflier lsm be used.

I am asking for your comments/suggestions on the following issues:
- security/correctness of the LSM (is there a way for a program to have access 
to a socket, and escaping the labeling?)
- how do I generate an SELinux policy, that does what this LSM module does?

If (and when) I succeed in writing this userspace policy generator, the 
fireflier lsm might be dropped, and replaced with the policy generator:
even if the user has no selinux policy & tools, he can use fireflier policy 
generator for labeling only, all he has to do, is boot with selinux=1.
However on many  distributions in that case a default policy is loaded, so we 
would have to deactivate that (we can't _require_ the user to actually have 
selinux set up). Not really a nice solution.
However dropping the lsm module can be done only in the fireflier 2.1, or 2.2 
it will most probably be included in fireflier 2.0 (currently in beta).
@Martin Maurer: what is your opinion on this?


Cheers,
Edwin
[1]http://www.uwsg.iu.edu/hypermail/linux/kernel/0604.0/0133.html

[RFC][PATCH 1/7] fireflier LSM for labeling sockets based on its creator (owner)

[Török Edwin]

Auto-labeling logic. This is where the (individual&group) SIDs are generated, 
and maintained.

---
 autolabel.c |  262 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 autolabel.h |   24 +++++
 constants.h |    7 +
 context.h   |   62 ++++++++++++++
 4 files changed, 355 insertions(+)
diff -uprN null/autolabel.c fireflier_lsm/autolabel.c
--- /dev/null	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/autolabel.c	2006-04-07 17:43:48.000000000 +0300
@@ -0,0 +1,262 @@
+/*
+ *  Fireflier security labeling module
+ *
+ *
+ *  This file contains the Fireflier auto-labeling implementations.
+ *
+ *  Copyright (C) 2006 Török Edwin <edwin@gurde.com>
+ *
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *	it under the terms of the GNU General Public License version 2,
+ *      as published by the Free Software Foundation.
+ */
+#include "autolabel.h"
+#include "sidtab.h"
+#include "constants.h"
+#include "fireflier_debug.h"
+#include "fireflier.h"
+/*
+  How all this works:
+
+  a SID is generated based on the file (mountpoint+inode), and it is used to 
label processes.
+  A SID of the process always refers to a single file, that of the process's 
executable.
+
+  In case of inodes (of files of a process), a SID can either be the SID of 
the _only_ process that has access to that file,
+  or if multiple processes have access to that file, then it is a "group 
SID".
+  A "group SID" is a list of all the executables that have access to that 
file.
+
+  The first time a file is created, it is labeled with the current tasks SID.
+  When another process gains access to that file, and that process has a 
different executable then the one that already has access to the file,
+  then the file's SID will be changed to a "group SID".
+  The file's SID will transition to this new group SID:
+  First we'll check if a group SID already exists for these  processes, and 
if so, that one will be used.
+  If not, we'll create another group.
+  
+  Note: we are not going to label all files, just sockets, but that doesn't 
have any impact on the labeling implementation
+*/
+
+//TODO: we will also need to remove unused SIDs?
+
+
+struct sidtab fireflier_sidtab;
+
+/**
+ * autolabel_init - initialize the sidtab
+ */
+int autolabel_init(void)
+{
+	return sidtab_init(&fireflier_sidtab);
+}
+
+
+/**
+ * getfile_from_sid - returns the execfile of this SID
+ * @tasksid: the SID of a task
+ */
+static inline const struct context* getcontext_from_sid(const u32 tasksid)
+{
+	const struct context* context = sidtab_search(&fireflier_sidtab,tasksid);
+	if(unlikely(context->groupmembers)) {
+		printk(KERN_DEBUG "Fireflier: programming logic error: a task's SID can't 
be a group SID!\n");
+		return NULL;
+	}
+	else
+		return context;
+}
+
+/**
+ * don't use NULL for empty device, use this empty string
+ */
+static char empty_dev[] = "";
+
+/**
+ * internal_get_or_generate_sid - returns a SID that uniqueuly identifies 
this devname+inode combination
+ * @devname - name of the mountpoint(device) the process's executable is on
+ * @inode - inode of the process's executable
+ * @unsafe - reason this process might be unsafe (ptrace,etc.)
+ */
+static inline u32 internal_get_or_generate_sid(const char* devname,const 
unsigned long inode,const char unsafe)
+{
+	u32 sid = FIREFLIER_SID_UNLABELED;
+	const struct context context=
+		{
+			.inode = inode,
+			.mnt_devname = unlikely(devname==NULL) ? empty_dev : devname,
+			.groupmembers = 0,
+			.unsafe = unsafe
+		};
+	sidtab_context_to_sid(&fireflier_sidtab,&context,&sid);
+
+	ff_debug_dump_sid(&context,sid);
+
+	return sid;
+}
+
+/**
+ * get_or_generate_unsafe_sid - generate a new SID because a task became 
unsafe
+ * @oldtasksid - the "safe" task's SID
+ * @unsafe - reason it became unsafe
+ * this generates a new SID, referring to the same inode+mountpoint as old 
SID, but with the added unsafe attribute
+ */
+u32 get_or_generate_unsafe_sid(const u32 oldtasksid,const char unsafe)
+{
+	const struct context* oldcontext = getcontext_from_sid(oldtasksid);
+	return 
internal_get_or_generate_sid(oldcontext->mnt_devname,oldcontext->inode,unsafe);
+}
+
+/**
+ * get_or_generate_sid - return a SID that uniquely identifies this file
+ * @execfile: file member of linux_binprm
+ * @unsafe: reason for this task to be unsafe (ptrace,..)
+ * wrapper around internal_get_or_generate_sid
+ */
+u32 get_or_generate_sid(const struct file* execfile,const char unsafe)
+{
+	return 
internal_get_or_generate_sid(execfile->f_vfsmnt->mnt_devname,execfile->f_dentry->d_inode->i_ino,unsafe);
+}
+
+/** fireflier_ctx_to_id - converts the mountpoint+inode to a SID
+ * @dev - the device (mountpoint) name - this will be copied
+ * @inode - the inode
+ * @ctxid - a pointer to where the SID will be stored
+ * this is intended to be called from the iptables match module
+ */
+int fireflier_ctx_to_id(const char* dev,unsigned long inode,u32 *ctxid)
+{
+	if(ctxid)
+	{
+//	   printk(KERN_DEBUG "fireflier_ctx_to_id: %s, %ld\n",dev,inode);
+		*ctxid=internal_get_or_generate_sid(kstrdup(dev,GFP_KERNEL),inode,0);
+		return 0;
+	}
+	return 1;
+}
+
+/**
+ * add_sid_to_group - returns a group that has tasksid added to it
+ * @oldgroup: the old group
+ * @tasksid: the SID to add to the old group
+ * If a group already exists that contains all sids in oldgroup, and the 
tsid, then it is used
+ * otherwise a new group is created
+ */
+static u32 add_sid_to_group(u32 oldgroup,u32 tasksid)
+{
+	const struct context* oldcontext = sidtab_search(&fireflier_sidtab,tasksid);
+	const int old_member_count = oldcontext->groupmembers==0 ? 1 : 
oldcontext->groupmembers;
+	struct context* newcontext = 
kmalloc(sizeof(*newcontext)+sizeof(u32)*(old_member_count+1),GFP_ATOMIC);
+	u32 sid = FIREFLIER_SID_UNLABELED;
+
+	/* If we are creating a group, then add the old sid, as first member */
+	if(old_member_count==1)
+		newcontext->sids[0]=oldgroup;
+	newcontext->mnt_devname=empty_dev;
+	newcontext->inode=0;
+
+	newcontext->groupmembers=old_member_count+1;
+	if(old_member_count!=1)
+		memcpy(&newcontext->sids,&oldcontext->sids,old_member_count);
+	newcontext->sids[old_member_count]=tasksid;
+
+	sidtab_context_to_sid(&fireflier_sidtab,newcontext,&sid);
+	ff_debug_dump_sid(newcontext,sid);
+	kfree(newcontext);
+
+	return sid;
+}
+
+static inline int is_sid_in_group(u32 sid,u32 group)
+{
+	const struct context* context = sidtab_search(&fireflier_sidtab,sid);
+	int i;
+	for(i=0;i<context->groupmembers;i++)
+		if(context->sids[i]==sid)
+			return 1;
+	return 0;
+}
+
+/**
+ * compute_inode_sid - calculates the new SID of this inode
+ * @oldinodesid: the old SID of this inode (if it had one)
+ * @tasksid: the tasks's SID
+ *
+ * This function calculates the new SID of an inode, it _has_ to be called 
each time a new
+ * task gains access to the file/socket identified by this inode.
+ * If the task's SID already matches (or is included in) the inode's SID, 
then that SID is used.
+ * Otherwise the task is added to a group SID.
+ */
+u32 compute_inode_sid(u32 oldinodesid,u32 tasksid)
+{
+//	printk(KERN_DEBUG "oldinode:%d, tasksid:%d",oldinodesid,tasksid);
+	if(likely(oldinodesid == tasksid))
+		return tasksid;
+	if(is_sid_in_group(tasksid,oldinodesid))
+		return oldinodesid;
+	return add_sid_to_group(oldinodesid,tasksid);
+}
+
+/**
+ * u32_compute_len - counts nr. of digits
+ */
+static inline int u32_compute_len(u32 value)
+{
+	int digits=0;
+	if(value==0)
+		return 1;
+	for(;value;digits++)
+		value /= 10;
+	return digits;	
+}
+/**
+ * fireflier_sid_to_context - returns string representation of sid
+ * @sid - sid to be converted
+ * @scontext -string representation - the list of mountpoint+inodes; NULL - 
query length
+ * @scontextlen - length of the string
+ */
+int fireflier_sid_to_context(u32 sid,char** scontext,u32* scontextlen)
+{
+	const struct context* context = sidtab_search(&fireflier_sidtab,sid);
+	const size_t mntdevlen = strlen(context->mnt_devname);
+	if(likely(!context->groupmembers)) {				
+		const size_t len  = mntdevlen + u32_compute_len(context->inode) + 2;
+		*scontextlen = len;
+		if(!scontext)
+			return -1;
+		if(!*scontext)
+			*scontext = (char*) kmalloc(len,GFP_ATOMIC);
+		if(!scontext)
+			return -ENOMEM;
+		snprintf(*scontext,len,"%s:%ld",context->mnt_devname,context->inode);		
+
+		return 0;		
+	}
+	else {
+		size_t len = mntdevlen + 1;
+		int i;
+		char* string;
+		for(i=0;i<context->groupmembers;i++) {
+			u32 len_sub;
+			fireflier_sid_to_context(context->sids[i],NULL,&len_sub);
+			len += len_sub-1;
+		}
+		*scontextlen = len+1;
+		if(!scontext)
+			return -1;
+		*scontext = (char*) kmalloc(len,GFP_ATOMIC);
+		if(!scontext)
+			return -ENOMEM;
+	        string = *scontext;
+		for(i=0;i<context->groupmembers;i++) {
+			u32 len_sub;
+			int err;
+			if((err=fireflier_sid_to_context(context->sids[i],&string,&len_sub)))
+				return err;
+			string += len_sub-1;
+		}
+
+		return 0;		
+			
+	}
+}
+
+EXPORT_SYMBOL_GPL(fireflier_ctx_to_id);
diff -uprN null/autolabel.h fireflier_lsm/autolabel.h
--- /dev/null	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/autolabel.h	2006-04-06 22:50:49.000000000 +0300
@@ -0,0 +1,24 @@
+/*
+ *  Fireflier security labeling module
+ *
+ *
+ *  This file contains the Fireflier auto-labeling implementations.
+ *
+ *  Copyright (C) 2006 Török Edwin <edwin@gurde.com>
+ *
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *	it under the terms of the GNU General Public License version 2,
+ *      as published by the Free Software Foundation.
+ */
+#ifndef _FF_AUTOLABEL_H_
+#define _FF_AUTOLABEL_H_
+#include <linux/types.h>
+#include <linux/file.h>
+
+u32 get_or_generate_sid(const struct file* execfile,const char unsafe);
+u32 get_or_generate_unsafe_sid(const u32 oldtasksid,const char unsafe);
+u32 compute_inode_sid(u32 oldinodesid,u32 tasksid);
+int fireflier_sid_to_context(u32 sid,char** scontext,u32* scontextlen);
+int autolabel_init(void);
+#endif
diff -uprN null/constants.h fireflier_lsm/constants.h
--- /dev/null	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/constants.h	2006-04-07 14:11:38.000000000 +0300
@@ -0,0 +1,7 @@
+#ifndef _FF_CONSTANTS_H_
+#define _FF_CONSTANTS_H_
+
+#define FIREFLIER_MAGIC 0xb81ff123
+#define FIREFLIER_SID_UNLABELED 0
+#define FIREFLIER_SECINITSID_KERNEL 1
+#endif
diff -uprN null/context.h fireflier_lsm/context.h
--- null/context.h	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/context.h	2006-03-29 23:23:57.000000000 +0300
@@ -0,0 +1,62 @@
+/*
+ *  Fireflier security labeling module
+ *
+ *
+ *  This file contains the Fireflier security context structures
+ *
+ *  Copyright (C) 2006 Török Edwin <edwin@gurde.com>
+ *
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *	it under the terms of the GNU General Public License version 2,
+ *      as published by the Free Software Foundation.
+ */
+
+#ifndef _FF_CONTEXT_H_
+#define _FF_CONTEXT_H_
+
+#include <linux/fs.h>
+#include <linux/dcache.h>
+#include <linux/mount.h>
+/* this is the context of our SID,
+ * actually it is the executable file (mountpoint+inode)
+ */
+struct context {
+	unsigned long inode;
+	const char* mnt_devname;	/* if this is a group SID, then this is NULL */
+	char groupmembers;/* nr. of group members, if it is 0 this is not a group, 
but a SID by itself*/
+	char unsafe;/* Reason for task being unsafe: ptrace,... */
+	/*if this is a group SID, then a list of group member SIDs follows*/
+	u32 sids[];
+};
+
+
+/**
+ * context_cmp - compares 2 contexts
+ * @a: the context to compare
+ * @b: the context to compare with
+ * Compares (for equality) the 2 fireflier security contexts
+ * it actually has to compare if the inode+mountpoint of the executable is 
the same
+ * and to compare group SIDs
+ */
+static inline int context_cmp(const struct context* a,const struct context* 
b)
+{
+	return (a->inode==b->inode) && !strcmp(a->mnt_devname,b->mnt_devname)
+		&& (a->groupmembers==b->groupmembers) &&
+		
(!a->groupmembers || !memcmp(&a->sids,&b->sids,a->groupmembers*sizeof(u32))) 
&&
+		(a->unsafe == b->unsafe) ;
+}
+
+/**
+ * context_cpy - copies a context
+ * @dest:  destination context
+ * @source: source context
+ *
+ */
+static inline void context_cpy(struct context** dest,const struct context* 
source)
+{
+	const size_t struct_size = sizeof(*source)+sizeof(u32)*source->groupmembers;
+	*dest = kmalloc(struct_size,GFP_ATOMIC);
+	memcpy(*dest,source,struct_size);
+}
+#endif

Re: [RFC][PATCH 1/7] fireflier LSM for labeling sockets based on its creator (owner)

[Stephen Smalley]

On Fri, 2006-04-07 at 21:27 +0300, Török Edwin wrote:
> Auto-labeling logic. This is where the (individual&group) SIDs are generated, 
> and maintained.

> diff -uprN null/autolabel.c fireflier_lsm/autolabel.c
> --- /dev/null	1970-01-01 02:00:00.000000000 +0200
> +++ fireflier_lsm/autolabel.c	2006-04-07 17:43:48.000000000 +0300
> +/**
> + * internal_get_or_generate_sid - returns a SID that uniqueuly identifies 
> this devname+inode combination
> + * @devname - name of the mountpoint(device) the process's executable is on
> + * @inode - inode of the process's executable
> + * @unsafe - reason this process might be unsafe (ptrace,etc.)
> + */
> +static inline u32 internal_get_or_generate_sid(const char* devname,const 
> unsigned long inode,const char unsafe)
> +{
> +	u32 sid = FIREFLIER_SID_UNLABELED;
> +	const struct context context=
> +		{
> +			.inode = inode,
> +			.mnt_devname = unlikely(devname==NULL) ? empty_dev : devname,
> +			.groupmembers = 0,
> +			.unsafe = unsafe
> +		};
> +	sidtab_context_to_sid(&fireflier_sidtab,&context,&sid);
<snip>
> +u32 get_or_generate_sid(const struct file* execfile,const char unsafe)
> +{
> +	return 
> internal_get_or_generate_sid(execfile->f_vfsmnt->mnt_devname,execfile->f_dentry->d_inode->i_ino,unsafe);
> +}

(mnt_devname, ino) pair is not a suitable basis here.  If you truly
cannot use inode extended attributes, then you might want to consider
using file handles.  It would help to understand how the userspace
component intends to use the supplied information, e.g. given some kind
of identifier or attribute for the subjects that have access to the
socket, what does the userspace component do with that identifier or
attribute?

-- 
Stephen Smalley
National Security Agency

Re: [RFC][PATCH 1/7] fireflier LSM for labeling sockets based on its creator (owner)

[Török Edwin]

On Wednesday 12 April 2006 22:11, Stephen Smalley wrote:
> On Fri, 2006-04-07 at 21:27 +0300, Török Edwin wrote:
> <snip>
>
> > +u32 get_or_generate_sid(const struct file* execfile,const char unsafe)
> > +{
> > +	return
> > internal_get_or_generate_sid(execfile->f_vfsmnt->mnt_devname,execfile->f_
> >dentry->d_inode->i_ino,unsafe); +}
>
> (mnt_devname, ino) pair is not a suitable basis here.  If you truly
> cannot use inode extended attributes, then you might want to consider
> using file handles.  It would help to understand how the userspace
> component intends to use the supplied information, e.g. given some kind
> of identifier or attribute for the subjects that have access to the
> socket, what does the userspace component do with that identifier or
> attribute?
The userspace will read the attribute using getxattr, and see if the programs 
being accessing the socket are allowed by its rules, and will set the verdict 
on the packet.
The xattr of the socket inode will be a list of inodes of programs accessing 
the socket.

Lookup algorithm:
- find out socket inode from /proc/net/tcp|udp|tcp6|udp6
- search /proc/pid/fd/* for sockets with the proper inode (iterates through 
all pids)
- getxattr -> match rules

The /proc search is cached, so its only done on the 1st packet received, after 
that /proc/pidlast/fd/lastfd is stat-ed, and if the inode is still the same, 
no further searching is done. If not, the cache for that socket inode is 
invalidated.

I could have also dropped the cache, and done a full /proc lookup to find out 
which processes have access to a socket, but I think you'll agree that this 
would have had a huge impact on performance.


Alternatively an iptables module can be used that matches based on security 
context (if the userspace /proc search would be too slow on a high-load 
connection for example).

P.S.: The userspace part that reads xattr isn't implemented yet.

Cheers,
Edwin

[RFC][PATCH 2/7] implementation of LSM hooks

[Török Edwin]

Implementation of the LSM hooks. It is based on hooks.c from SELinux. 
I replaced the avc with calls to functions from autolabel.c

Also, one important difference:
- when open files are checked during an execve, they are NOT closed when a 
domain transition occurs to a different sid. A group SID is created, and both 
the old sid, and new sids can be retrieved later.

How could I write an SELinux policy that does this?


---
 hooks.c      |  669 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 structures.h |   76 ++++++
 2 files changed, 745 insertions(+)

diff -uprN null/hooks.c fireflier_lsm/hooks.c
--- null/hooks.c	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/hooks.c	2006-04-07 17:43:37.000000000 +0300
@@ -0,0 +1,669 @@
+
+/*
+ *  Fireflier security labeling module
+ *
+ *
+ *  This file contains the Fireflier hook function implementations.
+ *
+ *  Based on the SELinux hooks.c
+ *
+ *  The Fireflier security module won't deny any operations
+ *  Its sole purpose is to label processes, and files, so that the sk_filter 
context match
+ *  will be able to do context matching without selinux being active
+ *
+ *  You shouldn't use SELinux and Fireflier LSM at the same time 
+ *  You can either have:
+ *   - Having SELinux compiled in your kernel, and disabled at boot, and 
fireflier enabled at boot /loaded as a module  
+ *   - Having SELinux compiled in your kernel, and enabled at boot, and 
fireflier disabled on boot/not loaded.
+ *	
+ *  Currently you have to turn off the capability module 
(capability.disable=1 on boot). See README for details
+ *
+ *  Copyright (C) 2006 Török Edwin <edwin@gurde.com>
+ *
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *	it under the terms of the GNU General Public License version 2,
+ *      as published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/security.h>
+
+#include <linux/mount.h>
+#include <linux/xattr.h>
+#include <net/sock.h>
+#include "fireflier_debug.h"
+#include "constants.h"
+#include "structures.h"
+#include "autolabel.h"
+
+//TODO: document all these functions here
+
+/* Original (dummy) security module. */
+static struct security_operations *original_ops = NULL;
+static struct security_operations *secondary_ops = NULL;
+static struct security_operations dummy_security_ops;
+
+
+#define XATTR_FIREFLIER_SUFFIX "fireflier"
+#define XATTR_NAME_FIREFLIER XATTR_SECURITY_PREFIX XATTR_FIREFLIER_SUFFIX
+
+
+/* module stacking operations */
+/**
+ * fireflier_register_security - register a stacked security module
+ * @name: the name of the secondary security module to register
+ * @ops:  the stacked module's security_operations 
+ */
+static int fireflier_register_security (const char *name, struct 
security_operations *ops)
+{
+        if (secondary_ops != original_ops)
+        {
+                printk(KERN_INFO "%s:  There is already a secondary 
security "
+                       "module registered.\n", __FUNCTION__);
+                return -EINVAL;
+        }
+	
+        secondary_ops = ops;
+	
+        printk(KERN_INFO "%s:  Registering secondary module %s\n",
+               __FUNCTION__,
+               name);
+
+        return 0;
+}
+
+/**
+ * fireflier_unregister_security - unregister a stacked security 
+ * @name: the name of the secondary security module to unregister
+ * @ops:  the security_operations of the stacked module
+ */
+static int fireflier_unregister_security (const char *name, struct 
security_operations *ops)
+{
+        if (ops != secondary_ops)
+        {
+                printk (KERN_INFO "%s:  trying to unregister a security 
module "
+                        "that is not registered.\n", __FUNCTION__);
+                return -EINVAL;
+        }
+
+        secondary_ops = original_ops;
+
+        return 0;
+}
+
+
+/**
+ * task_alloc_security - allocate the security structure for a task
+ * @task: the task to allocate the security structure for
+ * Allocates and initializes the security structure of a task.
+ * Returns -ENOMEM in case of an allocation failure.
+ * This function might sleep.
+ */
+static int task_alloc_security(struct task_struct *task)
+{
+	struct fireflier_task_security_struct *tsec;
+	
+	tsec = kzalloc(sizeof(*tsec), GFP_ATOMIC);
+	if (!tsec)
+		return -ENOMEM;
+	
+	tsec->magic = FIREFLIER_MAGIC;
+	tsec->task = task;
+	tsec->osid = tsec->sid = tsec->ptrace_sid = FIREFLIER_SID_UNLABELED;
+	task->security = tsec;
+	
+	return 0;
+}
+
+/**
+ * task_free_security - free the security structure of a task
+ */
+static void task_free_security(struct task_struct *task)
+{
+	struct fireflier_task_security_struct *tsec = task->security;
+	
+	if (!tsec || tsec->magic != FIREFLIER_MAGIC)
+		return;
+	
+	task->security = NULL;
+	kfree(tsec);
+}
+
+/**
+ * fireflier_task_alloc_security - allocate & initialize the security 
structure of tsk from current
+ * @tsk: the task who's security context needs to be initialized
+ * In case of allocation failure returns -ENOMEM
+ * otherwise calls secondary security module.
+ * Might sleep.
+ */
+static int fireflier_task_alloc_security(struct task_struct *tsk)
+{
+	struct fireflier_task_security_struct *tsec_current, *tsec_tsk;
+
+
+	int rc;
+	rc = task_alloc_security(tsk);
+	if (rc)
+		return rc;
+	tsec_current = current->security;
+	if(tsec_current) {
+		tsec_tsk = tsk->security;
+
+		tsec_tsk->sid = tsec_current->sid;
+		tsec_tsk->osid = tsec_current->osid;
+		/* Retain ptracer SID across fork, if any.
+		   This will be reset by the ptrace hook upon any
+		   subsequent ptrace_attach operations. */
+		tsec_tsk->ptrace_sid = tsec_current->ptrace_sid;
+	}
+	//else printk(KERN_DEBUG "current has no security info\n");
+	return secondary_ops->task_alloc_security(tsk);
+}
+
+
+/**
+ * fireflier_bprm_alloc_security - allocate & initialize a linux_bprm 
structure
+ * @bprm: the linux_bprm structure to initialize
+ * Returns -ENOMEM on allocation failure, otherwise calls stacked security 
module.
+ * Might sleep.
+ */
+static int fireflier_bprm_alloc_security(struct linux_binprm *bprm)
+{
+	struct fireflier_bprm_security_struct *bsec;
+
+	bsec = kzalloc(sizeof(*bsec), GFP_KERNEL);
+	if (!bsec)
+		return -ENOMEM;
+
+	bsec->magic = FIREFLIER_MAGIC;
+	bsec->bprm = bprm;
+	bsec->sid = FIREFLIER_SID_UNLABELED;
+	bsec->set = 0;
+
+	bprm->security = bsec;
+	
+	return secondary_ops->bprm_alloc_security(bprm);
+}
+
+/**
+ * fireflier_bprm_set_security - Sets the SID of bprm
+ * @bprm: linux_bprm structure, its SID will be calculated here
+ * This is where the (autolabeling) sid generation function is called, i.e.
+ * this function is responsible for computing the SID of the process that is 
going to be executed
+ * Calls secondary security module.
+ * Can this sleep?
+ */
+static int fireflier_bprm_set_security(struct linux_binprm *bprm)
+{
+	struct fireflier_bprm_security_struct *bsec;
+
+	bsec = bprm->security;
+	if(unlikely(!bsec)) {
+		printk(KERN_DEBUG "Fireflier: bprm->security not set\n");
+		return  secondary_ops->bprm_set_security(bprm);
+	}
+		
+	if (bsec->set)
+		return  secondary_ops->bprm_set_security(bprm);
+
+
+	bsec->sid = get_or_generate_sid(bprm->file,0);
+        printk(KERN_DEBUG "sid:%d\n",bsec->sid);
+	bsec->set = 1;
+	return  secondary_ops->bprm_set_security(bprm);
+}
+
+/**
+ * fireflier_bprm_free_security - free the binbprm's security structure
+ * @bprm: linux_binprm structure, who's security structure is to be freed
+ */
+static void fireflier_bprm_free_security(struct linux_binprm *bprm)
+{
+	BUG_ON(!bprm->security);
+	kfree(bprm->security);
+	bprm->security = NULL;
+	return secondary_ops->bprm_free_security(bprm);
+}
+
+/**
+ * fireflier_bprm_apply_creds - compute the sid of the current task based on 
bprm
+ * @bprm: linux_binprm structure
+ * @unsafe: reasons why the transition might be unsafe
+ * Compute the sid of a process being transformed by an execve operation
+ */
+static void fireflier_bprm_apply_creds(struct linux_binprm *bprm, int unsafe)
+{
+	struct fireflier_task_security_struct *tsec;
+	struct fireflier_bprm_security_struct *bsec;
+	u32 sid;
+
+
+	secondary_ops->bprm_apply_creds(bprm, unsafe);
+
+	tsec = current->security;
+	bsec = bprm->security;
+	if(unlikely(!bsec)) {
+		printk(KERN_DEBUG "No bprm security structure allocated\n");
+		dump_stack();
+		return;
+	}
+	sid = bsec->sid;
+
+
+	bsec->unsafe = 0;
+	if(unlikely(!tsec)) {
+		printk(KERN_DEBUG "No security structure allocated\n");
+		dump_stack();
+		return;
+	}
+	if (tsec->sid != sid) {
+		/* hmmm unsafe&ptrace stuff.... need to think over this a bit*/
+		if(unsafe & (LSM_UNSAFE_SHARE | LSM_UNSAFE_PTRACE|LSM_UNSAFE_PTRACE_CAP)) 
+		{	   
+		
+			printk(KERN_DEBUG "marking SID as unsafe\n");
+			bsec->unsafe=unsafe;
+		}
+	   
+		tsec->sid = sid;
+	}	
+}
+
+
+/**
+ * inode_update_perm - update the group SID of this inode
+ * @tsk - the task that has accesses the inode
+ * @inode - the inode who's SID has to be updated
+ * A task has accessed this file, add the task's SID to the group SID of 
tasks
+ * accessing the file
+ * based on inode_has_perm 
+ */
+static void inode_update_perm(struct task_struct *tsk,struct inode *inode)
+{
+	struct fireflier_task_security_struct *tsec;
+	struct fireflier_inode_security_struct *isec;
+
+     	tsec = tsk->security;
+   	isec = inode->i_security;
+   	if(!isec) 
+     		return;
+   
+     	if(unlikely(!tsec))
+       		isec->sid = compute_inode_sid(isec->sid,FIREFLIER_SID_UNLABELED);
+   	else
+     		isec->sid = compute_inode_sid(isec->sid,tsec->sid);
+   	printk(KERN_DEBUG "computed inode 
sid: %ld->%d\n",inode->i_ino,isec->sid);   
+}
+
+
+
+/** 
+ * file_update_perm - update the group SID of this file
+ * @tsk - the task that has accessed the file
+ * @file - the file that has been accessed
+ * A task has accessed this file, add the task's SID to the group SID of 
tasks
+ * accessing the file
+ * Based on file_has_perm 
+ */
+static  inline void file_update_perm(struct task_struct *tsk, struct file 
*file)    
+{
+   
+	struct fireflier_task_security_struct *tsec = tsk->security;
+	struct fireflier_file_security_struct *fsec = file->f_security;
+	struct dentry *dentry = file->f_dentry;
+	struct inode *inode = dentry->d_inode;
+   
+	inode_update_perm(tsk, inode);
+   
+	if(!fsec)
+		return;
+	if(unlikely(!tsec))
+		fsec->sid=compute_inode_sid(fsec->sid,FIREFLIER_SID_UNLABELED);
+	else
+		fsec->sid=compute_inode_sid(fsec->sid,tsec->sid);
+}
+
+
+  
+ 
+/** 
+ * update_files_auth - update the group SID of the files
+ * @files - a files_struct containing all files of the forked process
+ * Derived from fs/exec.c:flush_old_files. 
+ *  Should deal only with sockets 
+ */
+static inline void update_files_auth(struct files_struct * files)  
+{
+   
+   
+	struct file *file;
+	struct fdtable *fdt;
+	long j = -1;
+  
+	/* Revalidate access to inherited open files. */
+	spin_lock(&files->file_lock);
+	for (;;) 
+	{
+		unsigned long set, i;
+	
+		j++;
+		i = j * __NFDBITS;
+		fdt = files_fdtable(files);
+		if (i >= fdt->max_fds || i >= fdt->max_fdset)
+			break;
+		set = fdt->open_fds->fds_bits[j];
+		if (!set)
+			continue;
+		spin_unlock(&files->file_lock);
+		for ( ; set ; i++,set >>= 1) 
+		{
+			if (set & 1) 
+			{
+				file = fget(i);
+				if (!file)
+					continue;
+				file_update_perm(current,file);
+				fput(file);
+			}
+		}
+		spin_lock(&files->file_lock);
+	}
+	spin_unlock(&files->file_lock);
+}
+
+	 
+/**
+ * fireflier_bprm_post_apply_creds - updates files' SID
+ * @bprm - a linux_bprm structure
+ * update the security field of bprm
+ */
+static void fireflier_bprm_post_apply_creds(struct linux_binprm *bprm)
+{
+	struct fireflier_task_security_struct *tsec = current->security;
+	struct fireflier_bprm_security_struct *bsec  = bprm->security;
+	secondary_ops->bprm_post_apply_creds(bprm);
+	
+	if(bsec->unsafe) 
+	{
+	
+		printk(KERN_DEBUG "computing unsafe SID\n");
+		tsec->sid = get_or_generate_unsafe_sid(tsec->sid,bsec->unsafe);
+	
+	}
+   
+	ff_debug_map_pidsid(tsec->sid);
+	if (tsec->osid == tsec->sid)
+		return;
+   	//SID changed, so update the files's SIDs, i.e. turn them into group SIDs
+	update_files_auth(current->files);
+}
+
+/**
+ * fireflier_inode_alloc_security - allocate the security structure of an 
inode
+ * @inode - inode
+ * allocate the security field of inode
+ */
+static int inode_alloc_security(struct inode *inode)
+{
+	struct fireflier_task_security_struct *tsec = current->security;
+	struct fireflier_inode_security_struct *isec;
+	     
+	isec = kzalloc(sizeof(struct fireflier_inode_security_struct), GFP_KERNEL);
+	if (!isec)
+		return -ENOMEM;
+	     
+	INIT_LIST_HEAD(&isec->list);
+	isec->magic = FIREFLIER_MAGIC;
+	isec->inode = inode;
+	//isec->sclass = SECCLASS_FILE;
+	if (tsec && tsec->magic == FIREFLIER_MAGIC)
+		isec->sid = tsec->sid;
+	else
+		isec->sid = FIREFLIER_SID_UNLABELED;
+	inode->i_security = isec;
+	return 0;
+}
+	
+/**
+ * fireflier_inode_free_security - free the security structure of the inode
+ * @inode - inode
+ * free the security field of inode
+ */
+static void fireflier_inode_free_security(struct inode *inode)
+{
+	struct fireflier_inode_security_struct *isec = inode->i_security;
+//	struct fireflier_superblock_security_struct *sbsec = 
inode->i_sb->s_security;
+	     
+	secondary_ops->inode_free_security(inode);
+	if (!isec || isec->magic != FIREFLIER_MAGIC)// || !sbsec)
+		return;
+	     
+//	spin_lock(&sbsec->isec_lock);
+	if (!list_empty(&isec->list))
+		list_del_init(&isec->list);
+//	spin_unlock(&sbsec->isec_lock);
+	     
+	inode->i_security = NULL;
+	kfree(isec);
+}
+
+static int fireflier_socket_accept(struct socket *sock, struct socket 
*newsock)
+{
+	struct fireflier_inode_security_struct *isec = SOCK_INODE(sock)->i_security;        
+        struct inode* newinode = SOCK_INODE(newsock);
+	struct fireflier_inode_security_struct *newisec;
+   
+        inode_alloc_security(newinode);
+   
+        newisec = newinode->i_security;    
+        newisec->sid = isec->sid;
+   
+	return secondary_ops->socket_accept(sock,newsock);
+}
+	
+/** fireflier_file_receive - file received (via SysV IPC?)
+ * update group SID of file
+ */
+
+static int fireflier_file_receive(struct file* file)
+{
+	file_update_perm(current,file);
+	return secondary_ops->file_receive(file);
+}
+
+/*
+ * Copy the in-core inode security context value to the user.  If the
+ * getxattr() prior to this succeeded, check to see if we need to
+ * canonicalize the value to be finally returned to the user.
+ *
+ * Permission check is handled by selinux_inode_getxattr hook.
+ */
+static int fireflier_inode_getsecurity(struct inode *inode, const char *name, 
void *buffer, size_t size, int err)
+{
+	struct fireflier_inode_security_struct *isec = inode->i_security;
+	char *context=NULL;/* required!*/
+	unsigned len;
+	int rc;
+
+	if (strcmp(name, XATTR_FIREFLIER_SUFFIX) || !isec) {
+		rc = -EOPNOTSUPP;
+		goto out;
+	}
+     
+	rc = fireflier_sid_to_context(isec->sid, &context, &len);
+	if (rc)
+		goto out;
+
+	/* Probe for required buffer size */
+	if (!buffer || !size) {
+		rc = len;
+		goto out_free;
+	}
+
+	if (size < len) {
+		rc = -ERANGE;
+		goto out_free;
+	}
+
+	if (err > 0) {
+		if ((len == err) && !(memcmp(context, buffer, len))) {
+			/* Don't need to canonicalize value */
+			rc = err;
+			goto out_free;
+		}
+		memset(buffer, 0, size);
+	}
+	memcpy(buffer, context, len);
+	rc = len;
+ out_free:
+	kfree(context);
+ out:
+	return secondary_ops->inode_getsecurity(inode,name,buffer,size,err);
+}
+
+static int fireflier_inode_listsecurity(struct inode *inode, char *buffer, 
size_t buffer_size)
+{
+	if(inode->i_security) 
+	{
+	
+		const int len = sizeof(XATTR_NAME_FIREFLIER);
+		if (buffer && len <= buffer_size)
+			memcpy(buffer, XATTR_NAME_FIREFLIER, len);
+		return len+
+			secondary_ops->inode_listsecurity(inode,buffer+len,buffer_size-len);
+	}
+	else 
+		return 0;
+   
+
+}
+
+static void fireflier_socket_post_create(struct socket *sock, int family,
+					 int type, int protocol, int kern)
+{
+	struct fireflier_inode_security_struct *isec;
+	struct fireflier_task_security_struct *tsec = current->security;
+        struct inode* inode=SOCK_INODE(sock);
+   
+	secondary_ops->socket_post_create(sock,family,type,protocol,kern);
+	
+        inode_alloc_security(inode);
+	isec = inode->i_security;
+   
+	isec->sid = kern ? FIREFLIER_SECINITSID_KERNEL : tsec->sid;
+		
+	return;
+}
+
+/**
+ * fireflier_ops - our security_operations hooks
+ * Unused security hooks will be automatically redirected to the dummy 
security module
+ * Does the dummy module call the secondary module? Maybe we should implement 
all the hooks, and call
+ * the secondary module
+ */
+static struct security_operations fireflier_ops =
+{
+	.bprm_alloc_security  	= fireflier_bprm_alloc_security,
+	.bprm_free_security  	= fireflier_bprm_free_security,
+	.bprm_apply_creds  	= fireflier_bprm_apply_creds,
+	.bprm_post_apply_creds  = fireflier_bprm_post_apply_creds,
+	.bprm_set_security 	= fireflier_bprm_set_security,
+	.inode_free_security 	= fireflier_inode_free_security,
+    	.inode_getsecurity 	= fireflier_inode_getsecurity,
+   	.inode_listsecurity 	= fireflier_inode_listsecurity,
+	.file_receive 		= fireflier_file_receive,
+	.task_alloc_security 	= fireflier_task_alloc_security,
+	.task_free_security 	= task_free_security,
+	.socket_post_create 	= fireflier_socket_post_create,
+	.socket_accept 		= fireflier_socket_accept,
+	.register_security 	= fireflier_register_security,
+	.unregister_security 	= fireflier_unregister_security,
+};
+
+/**
+ * stacked - is a secondary module registered
+ */
+static int stacked=0;
+
+/**
+ * label_all_processes - labels already running processes
+ * Can this be done at all? Or do we need to have fireflier loaded during 
boot?
+ */
+static void label_all_processes(void)
+{
+	/* Labeling running processes without using the task_lock seems not possible 
for now*/
+        /* TODO: label processes that are already running */
+        /* TODO: prevent processes from being spawned while we label the 
running ones */
+	/* TODO Priority:Low, it works without this too */
+}
+
+/**
+ * fireflier_cleanup - Cleans up fireflier module
+ * Unregisters security module
+ */
+static void __exit fireflier_cleanup(void)
+{
+	if(stacked) {
+		if(mod_unreg_security("fireflier",&fireflier_ops))
+			printk(KERN_ERR "Fireflier: Error unregistering stacked security module.
\n");
+	}
+	else
+		if(unregister_security(&fireflier_ops))
+			printk(KERN_ERR "Fireflier: Error unregistering security module.\n");
+}
+
+int ff_debug;
+module_param(ff_debug,int,0);
+MODULE_PARM_DESC(ff_debug,"Enable debug info dumping in debugfs");
+/**
+ * fireflier_init - module loading initialization
+ * Registers fireflier as primary or secondary security module
+ */
+static int __init fireflier_init(void)
+{
+        /*Register security_ops with kernel*/
+        int err;
+
+        original_ops = security_ops;
+        /* initialize dummy_security_ops to dummy ops */
+        register_security(&dummy_security_ops);
+        unregister_security(&dummy_security_ops);
+        secondary_ops = &dummy_security_ops;//avoid recursion with capability 
module
+        if (!secondary_ops) {
+                printk (KERN_ERR "Fireflier: No initial security 
operations\n");
+                return -EAGAIN;
+        }
+        if ((err=register_security (&fireflier_ops))) {
+                printk(KERN_INFO "Fireflier: Unable to register as primary 
security module. Attempting to register as stacked security module\n");
+                stacked=1;
+                if((err=mod_reg_security("fireflier",&fireflier_ops))) {
+                        printk(KERN_ERR "Fireflier: Unable to register with 
kernel.\n");
+                        return err;
+                }
+        }
+        else
+                stacked=0;
+        /* Do initialization */
+	if((err=autolabel_init())) {
+		printk(KERN_ERR "Fireflier: autolabeling initialization failed (OOM?)\n");
+		fireflier_cleanup();
+		return err;
+	}
+        label_all_processes();
+	
+	/* Debugging stuff */
+	ff_debug_startup();
+	
+        return 0;
+}
+
+security_initcall(fireflier_init);
+module_exit(fireflier_cleanup);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Török Edwin <edwin@gurde.com>");
+MODULE_DESCRIPTION("Fireflier security module");
+MODULE_VERSION("0.01");
+
diff -uprN null/structures.h fireflier_lsm/structures.h
--- null/structures.h	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/structures.h	2006-04-07 14:41:30.000000000 +0300
@@ -0,0 +1,76 @@
+/*
+ *  Fireflier security labeling module
+ *
+ *
+ *  This file contains the Fireflier hook function implementations.
+ *
+ *  Based on the SELinux hooks.c
+ *
+ *  Copyright (C) 2006 Török Edwin <edwin@gurde.com>
+ *
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *	it under the terms of the GNU General Public License version 2,
+ *      as published by the Free Software Foundation.
+ */
+#ifndef _FF_STRUCTURES_H_
+#define _FF_STRUCTURES_H_
+#include <linux/list.h>
+#include <linux/spinlock.h>
+#include "constants.h"
+/* Structures copied from SELinux, and prefixed with fireflier_ to avoid 
conflicts
+ * I don't want to use SELinux internal structures.
+ */ 
+ 
+ 
+struct fireflier_task_security_struct {
+	unsigned long magic;           /* magic number for this module */
+	struct task_struct *task;      /* back pointer to task object */
+	u32 sid;             /* current SID */
+	u32 osid;	     /* SID prior to execve */
+	u32 ptrace_sid;      /* SID of ptrace parent */
+};
+
+struct fireflier_inode_security_struct {
+	unsigned long magic;           /* magic number for this module */
+	struct inode *inode;           /* back pointer to inode object */
+	struct list_head list;         /* list of inode_security_struct */
+	u32 task_sid;        /* SID of creating task */
+	u32 sid;             /* SID of this object */
+	u16 sclass;       /* security class of this object */
+	unsigned char initialized;     /* initialization flag */
+	unsigned char inherit;         /* inherit SID from parent entry */
+};
+
+struct fireflier_file_security_struct {
+	unsigned long magic;            /* magic number for this module */
+	struct file *file;              /* back pointer to file object */
+	u32 sid;              /* SID of open file description */
+	u32 fown_sid;         /* SID of file owner (for SIGIO) */
+};
+
+struct fireflier_bprm_security_struct {
+	unsigned long magic;           /* magic number for this module */
+	struct linux_binprm *bprm;     /* back pointer to bprm object */
+	u32 sid;                       /* SID for transformed process */
+	unsigned char set;
+
+	/*
+	 * unsafe is used to share failure information from bprm_apply_creds()
+	 * to bprm_post_apply_creds().
+	 */
+	char unsafe;
+};
+/**
+ * getsid_safe - returns the SID, safe to be called with a  NULL pointer
+ * @tsec: a task's security structure to get the SID from, it can be NULL
+ */
+static inline u32 getsid_safe(const struct fireflier_task_security_struct* 
tsec)
+{
+	if(likely(tsec))
+		return tsec->sid;
+	else
+		return FIREFLIER_SID_UNLABELED;
+}
+
+#endif

Re: [RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Fri, 2006-04-07 at 21:38 +0300, Török Edwin wrote:
> Implementation of the LSM hooks. It is based on hooks.c from SELinux. 
> I replaced the avc with calls to functions from autolabel.c
> 
> Also, one important difference:
> - when open files are checked during an execve, they are NOT closed when a 
> domain transition occurs to a different sid. A group SID is created, and both 
> the old sid, and new sids can be retrieved later.
> 
> How could I write an SELinux policy that does this?

I don't think you can without further changes to SELinux, as you are
mutating object labels in response to events (aka floating labels).  But
the real question is why do you want to, i.e. what is actual functional
requirement, not just how you have chosen to implement it.

> diff -uprN null/hooks.c fireflier_lsm/hooks.c
> --- null/hooks.c	1970-01-01 02:00:00.000000000 +0200
> +++ fireflier_lsm/hooks.c	2006-04-07 17:43:37.000000000 +0300
> + * This function might sleep.
> + */
> +static int task_alloc_security(struct task_struct *task)
> +{
> +	struct fireflier_task_security_struct *tsec;
> +	
> +	tsec = kzalloc(sizeof(*tsec), GFP_ATOMIC);

Why GFP_ATOMIC?

> +	if (!tsec)
> +		return -ENOMEM;
> +	
> +	tsec->magic = FIREFLIER_MAGIC;

Drop the magic fields and tests; they are a relic of early LSM
development and have been dropped from SELinux.  Also you should
naturally drop any fields you aren't using.

> +static int fireflier_task_alloc_security(struct task_struct *tsk)
> +{
> +	struct fireflier_task_security_struct *tsec_current, *tsec_tsk;
> +
> +
> +	int rc;
> +	rc = task_alloc_security(tsk);
> +	if (rc)
> +		return rc;
> +	tsec_current = current->security;
> +	if(tsec_current) {

Better if you can guarantee that all tasks have a security structure,
either via early initialization or by processing them all during your
own initialization.

> +	return secondary_ops->task_alloc_security(tsk);

Don't call a secondary module hook unless you truly need it and know
that it can work.  In particular, alloc_security hooks can't work
properly without some mechanism for sharing the security field, so no
point in doing this here.

> +static int fireflier_bprm_set_security(struct linux_binprm *bprm)
> +{
> +	struct fireflier_bprm_security_struct *bsec;
> +
> +	bsec = bprm->security;
> +	if(unlikely(!bsec)) {
> +		printk(KERN_DEBUG "Fireflier: bprm->security not set\n");

Shouldn't be possible since you are allocating one in the other hook,
right, so don't test for such conditions.  You don't gain anything, and
you may hide or lose useful info that you would have gotten from the
Oops if it did occur.  Naturally the printks have to go for real use.

> +/**
> + * fireflier_bprm_free_security - free the binbprm's security structure
> + * @bprm: linux_binprm structure, who's security structure is to be freed
> + */
> +static void fireflier_bprm_free_security(struct linux_binprm *bprm)
> +{
> +	BUG_ON(!bprm->security);

Again, it doesn't serve any real purpose to have this kind of test.

> +	kfree(bprm->security);
> +	bprm->security = NULL;
> +	return secondary_ops->bprm_free_security(bprm);

And calling a secondary module here isn't likely to work anyway.

> +static void fireflier_bprm_apply_creds(struct linux_binprm *bprm, int unsafe)
> +{
> +	struct fireflier_task_security_struct *tsec;
> +	struct fireflier_bprm_security_struct *bsec;
> +	u32 sid;
> +
> +
> +	secondary_ops->bprm_apply_creds(bprm, unsafe);
> +
> +	tsec = current->security;
> +	bsec = bprm->security;
> +	if(unlikely(!bsec)) {
> +		printk(KERN_DEBUG "No bprm security structure allocated\n");
> +		dump_stack();
> +		return;
> +	}

Again, drop the test and let it Oops if it happens.

> +	sid = bsec->sid;
> +
> +
> +	bsec->unsafe = 0;
> +	if(unlikely(!tsec)) {
> +		printk(KERN_DEBUG "No security structure allocated\n");
> +		dump_stack();
> +		return;
> +	}

Ditto.

> +/**
> + * inode_update_perm - update the group SID of this inode
> + * @tsk - the task that has accesses the inode
> + * @inode - the inode who's SID has to be updated
> + * A task has accessed this file, add the task's SID to the group SID of 
> tasks
> + * accessing the file
> + * based on inode_has_perm 
> + */
> +static void inode_update_perm(struct task_struct *tsk,struct inode *inode)
> +{
> +	struct fireflier_task_security_struct *tsec;
> +	struct fireflier_inode_security_struct *isec;
> +
> +     	tsec = tsk->security;
> +   	isec = inode->i_security;
> +   	if(!isec) 
> +     		return;
> +   
> +     	if(unlikely(!tsec))
> +       		isec->sid = compute_inode_sid(isec->sid,FIREFLIER_SID_UNLABELED);
> +   	else
> +     		isec->sid = compute_inode_sid(isec->sid,tsec->sid);
> +   	printk(KERN_DEBUG "computed inode 
> sid: %ld->%d\n",inode->i_ino,isec->sid);   
> +}

Locking?  You are mutating the inode's SID, but many different tasks may
be accessing (in this case, inheriting/receiving a descriptor to) the
inode simultaneously.  Not clear that SIDs are even the right primitive
for what you are doing here, essentially aggregating a list of all
subjects that have gained a descriptor to the socket.  

> +static  inline void file_update_perm(struct task_struct *tsk, struct file 
> *file)    
> +{
> +   
> +	struct fireflier_task_security_struct *tsec = tsk->security;
> +	struct fireflier_file_security_struct *fsec = file->f_security;
> +	struct dentry *dentry = file->f_dentry;
> +	struct inode *inode = dentry->d_inode;
> +   
> +	inode_update_perm(tsk, inode);
> +   
> +	if(!fsec)
> +		return;
> +	if(unlikely(!tsec))
> +		fsec->sid=compute_inode_sid(fsec->sid,FIREFLIER_SID_UNLABELED);
> +	else
> +		fsec->sid=compute_inode_sid(fsec->sid,tsec->sid);

As before, locking required for safety.  But also - where do you use
this fsec->sid for anything (vs. the isec->sid)?

> +static int fireflier_inode_getsecurity(struct inode *inode, const char *name, 
> void *buffer, size_t size, int err)
> +{
<snip>
> +	if (err > 0) {
> +		if ((len == err) && !(memcmp(context, buffer, len))) {
> +			/* Don't need to canonicalize value */
> +			rc = err;
> +			goto out_free;
> +		}
> +		memset(buffer, 0, size);

IIUC, since you are dealing with sockets, this case is extraneous for
you.  In SELinux, it only exists for the case where you have an on-disk
xattr that already matches the incore representation, and is actually
eliminated in recent patches altogether.

> +	}
> +	memcpy(buffer, context, len);
> +	rc = len;
> + out_free:
> +	kfree(context);
> + out:
> +	return secondary_ops->inode_getsecurity(inode,name,buffer,size,err);
> +}

If there is a secondary module that implements that hook, won't it end
up clobbering what you just put into the buffer (and you lose the rc
value here)?  Again, drop any secondary hooks that you don't need and
that can't work in the absence of a real stacking solution.

> +
> +static int fireflier_inode_listsecurity(struct inode *inode, char *buffer, 
> size_t buffer_size)
> +{
> +	if(inode->i_security) 
> +	{
> +	
> +		const int len = sizeof(XATTR_NAME_FIREFLIER);
> +		if (buffer && len <= buffer_size)
> +			memcpy(buffer, XATTR_NAME_FIREFLIER, len);
> +		return len+
> +			secondary_ops->inode_listsecurity(inode,buffer+len,buffer_size-len);

What if len > buffer_size?  But as before, don't bother calling
secondary here unless you can actually make it work and have a need for
it.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Török Edwin]

On Wednesday 12 April 2006 20:42, Stephen Smalley wrote:
> On Fri, 2006-04-07 at 21:38 +0300, Török Edwin wrote:
> > How could I write an SELinux policy that does this?
>
> I don't think you can without further changes to SELinux, as you are
> mutating object labels in response to events (aka floating labels).
Would there be a reason to implement floating labels in SELinux?
How can I substitute floating labels (i.e. what would be its closest 
approximation)?
> But 
> the real question is why do you want to, i.e. what is actual functional
> requirement, 
Functional requirement:
- be able to control/know which programs have access to the internet
- be able to control/know which processes have access to a certain socket
- be able to control/know which processes share a socket, and which processes 
are the only ones accessing a socket

I used the term 'control/know', because I don't actually want to restrict the 
applications by using fireflier lsm, I just want it to provide information to 
its userspace part.

-- plan for fireflier SELinux integration (fireflier target version 2.1)---

Possible approaches I thought of:
1)  put programs needing to share a socket in the same domain, and match based 
on the domain of the socket. But what happens if a program would need to be 
in 2  or more domains (xinetd comes to mind)
But a problem remains: if there is a base policy that sets a context on a 
program, and  my module would try to set a domain for it too, won't they 
conflict? 

2) each program has its own domain, and xinetd is in a domain of its own, but 
it has access to all the sockets of its childs (domains). The same for 
postfix
Also run selinux in non-enforcing mode, with avc logging turned off. I only 
need labeling, not restrictions.



3)Or should I assume, that if a user has a base policy set up, he has 
configured that properly, and only those programs share sockets, that he 
intends to?
In this case fireflier would need to do only this:
- if selinux is disabled, then run a policy generator, that generates a base 
policy (not necessarely a module). fireflier will make sure user runs with 
selinux enabled, avc logging off, enforcing off
- if selinux is enabled, fireflier won't do shared socket checks, assuming 
that the policy will limit the sharing of sockets

Important question: can a file's context be set from the policy? 
(without using setfiles, to relabel the file, the user might want to enable 
selinux later, I don't want to mess up his labeling)
(this might sound silly: can a define a default auto-transition to a context?)

Looking at this now, it seems that 2+3 would be the best solution. Is there 
anything I need to take care of, when starting to implement 2+3?

When (and if) (2+3) will be completed, fireflier lsm will make no sense, and 
will be dropped. In the mean-time I'll try to make fireflier lsm usable.
----------------------------------------------------------

> not just how you have chosen to implement it. 

>
> > diff -uprN null/hooks.c fireflier_lsm/hooks.c
> > --- null/hooks.c	1970-01-01 02:00:00.000000000 +0200
> > +++ fireflier_lsm/hooks.c	2006-04-07 17:43:37.000000000 +0300
> > + * This function might sleep.
> > + */
> > +static int task_alloc_security(struct task_struct *task)
> > +{
> > +	struct fireflier_task_security_struct *tsec;
> > +
> > +	tsec = kzalloc(sizeof(*tsec), GFP_ATOMIC);
>
> Why GFP_ATOMIC?
Oops, that should have been GFP_KERNEL
>
> > +	if (!tsec)
> > +		return -ENOMEM;
> > +
> > +	tsec->magic = FIREFLIER_MAGIC;
>
> Drop the magic fields and tests; they are a relic of early LSM
> development and have been dropped from SELinux.  Also you should
> naturally drop any fields you aren't using.
Good point.
>
> > +	tsec_current = current->security;
> > +	if(tsec_current) {
>
> Better if you can guarantee that all tasks have a security structure,
> either via early initialization 
To have all tasks assigned a security structure, fireflier lsm needs to be 
compiled into the kernel.
> or by processing them all during your 
> own initialization.
I thought of this, see label_all_processes. Unfortunately I found no way of 
actually doing this. I would need to iterate through the tasklist structure, 
but the task_lock export is going to be removed from the kernel.
>
> > +	return secondary_ops->task_alloc_security(tsk);
>
> Don't call a secondary module hook unless you truly need it and know
> that it can work.  In particular, alloc_security hooks can't work
> properly without some mechanism for sharing the security field, so no
> point in doing this here.
Ok deleted most, except
bprm_set_security,bprm_apply_creds,bprm_post_apply_creds,socket_accept,file_receive, 
socket_post_create
>
> > +static int fireflier_bprm_set_security(struct linux_binprm *bprm)
> > +{
> > +	struct fireflier_bprm_security_struct *bsec;
> > +
> > +	bsec = bprm->security;
> > +	if(unlikely(!bsec)) {
> > +		printk(KERN_DEBUG "Fireflier: bprm->security not set\n");
>
> Shouldn't be possible since you are allocating one in the other hook,
> right, so don't test for such conditions.  You don't gain anything, and
> you may hide or lose useful info that you would have gotten from the
> Oops if it did occur.  
Ok
> Naturally the printks have to go for real use. 
I know
> <snip>
>
> > +/**
> > + * inode_update_perm - update the group SID of this inode
> > + * @tsk - the task that has accesses the inode
> > + * @inode - the inode who's SID has to be updated
> > + * A task has accessed this file, add the task's SID to the group SID of
> > tasks
> > + * accessing the file
> > + * based on inode_has_perm
> > + */
> > +static void inode_update_perm(struct task_struct *tsk,struct inode
> > *inode) +{
> > +	struct fireflier_task_security_struct *tsec;
> > +	struct fireflier_inode_security_struct *isec;
> > +
> > +     	tsec = tsk->security;
> > +   	isec = inode->i_security;
> > +   	if(!isec)
> > +     		return;
> > +
> > +     	if(unlikely(!tsec))
> > +       		isec->sid =
> > compute_inode_sid(isec->sid,FIREFLIER_SID_UNLABELED); +   	else
> > +     		isec->sid = compute_inode_sid(isec->sid,tsec->sid);
> > +   	printk(KERN_DEBUG "computed inode
> > sid: %ld->%d\n",inode->i_ino,isec->sid);
> > +}
>
> Locking?  You are mutating the inode's SID, but many different tasks may
> be accessing (in this case, inheriting/receiving a descriptor to) the
> inode simultaneously.  
Locking added. I use a lock every time the inode's sid is modified.
> Not clear that SIDs are even the right primitive 
> for what you are doing here, essentially aggregating a list of all
> subjects that have gained a descriptor to the socket.
The term 'SID' might not fit what I actually do here, true. Should I call it: 
access_id, ?
>
> > +static  inline void file_update_perm(struct task_struct *tsk, struct
> > file *file)
> > +{
> > +
> > +	struct fireflier_task_security_struct *tsec = tsk->security;
> > +	struct fireflier_file_security_struct *fsec = file->f_security;
> > +	struct dentry *dentry = file->f_dentry;
> > +	struct inode *inode = dentry->d_inode;
> > +
> > +	inode_update_perm(tsk, inode);
> > +
> > +	if(!fsec)
> > +		return;
> > +	if(unlikely(!tsec))
> > +		fsec->sid=compute_inode_sid(fsec->sid,FIREFLIER_SID_UNLABELED);
> > +	else
> > +		fsec->sid=compute_inode_sid(fsec->sid,tsec->sid);
>
> As before, locking required for safety.  But also - where do you use
> this fsec->sid for anything (vs. the isec->sid)?
Thanks for noticing, I don't use that anywhere, inode security labels are 
enough. Deleted now.
>
> > +static int fireflier_inode_getsecurity(struct inode *inode, const char
> > *name, void *buffer, size_t size, int err)
> > +{
>
> <snip>
>
> > +	if (err > 0) {
> > +		if ((len == err) && !(memcmp(context, buffer, len))) {
> > +			/* Don't need to canonicalize value */
> > +			rc = err;
> > +			goto out_free;
> > +		}
> > +		memset(buffer, 0, size);
>
> IIUC, since you are dealing with sockets, this case is extraneous for
> you.  In SELinux, it only exists for the case where you have an on-disk
> xattr that already matches the incore representation, and is actually
> eliminated in recent patches altogether.
Deleted. These are the disadvantages of not using a common code base, when 
selinux gets updated, fireflier doesn't. It would be best if I could avoid 
this situation. When (and if) I write the fireflier policy generator for 
selinux, fireflier lsm won't be needed anymore.
> <snip>


P.S.: Thanks for taking time to provide detailed explanations. Sorry for my 
late reply, I needed to think this over before replying.

I resend the hooks.c, and structures, with the modifications you suggested:

Cheers,
Edwin

---------
 hooks.c      |  631 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 structures.h |   62 +++++
 2 files changed, 693 insertions(+)

diff -uprN null/hooks.c fireflier_lsm/hooks.c
--- null/hooks.c	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/hooks.c	2006-04-14 22:53:40.000000000 +0300
@@ -0,0 +1,631 @@
+
+/*
+ *  Fireflier security labeling module
+ *
+ *
+ *  This file contains the Fireflier hook function implementations.
+ *
+ *  Based on the SELinux hooks.c
+ *
+ *  The Fireflier security module won't deny any operations
+ *  Its sole purpose is to label processes, and files, so that the sk_filter 
context match
+ *  will be able to do context matching without selinux being active
+ *
+ *  You shouldn't use SELinux and Fireflier LSM at the same time 
+ *  You can either have:
+ *   - Having SELinux compiled in your kernel, and disabled at boot, and 
fireflier enabled at boot /loaded as a module  
+ *   - Having SELinux compiled in your kernel, and enabled at boot, and 
fireflier disabled on boot/not loaded.
+ *	
+ *  Currently you have to turn off the capability module 
(capability.disable=1 on boot). See README for details
+ *
+ *  Copyright (C) 2006 Török Edwin <edwin@gurde.com>
+ *
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *	it under the terms of the GNU General Public License version 2,
+ *      as published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/security.h>
+
+#include <linux/mount.h>
+#include <linux/xattr.h>
+#include <net/sock.h>
+#include "fireflier_debug.h"
+#include "constants.h"
+#include "structures.h"
+#include "autolabel.h"
+
+//TODO: document all these functions here
+
+/* Original (dummy) security module. */
+static struct security_operations *original_ops = NULL;
+static struct security_operations *secondary_ops = NULL;
+static struct security_operations dummy_security_ops;
+
+
+#define XATTR_FIREFLIER_SUFFIX "fireflier"
+#define XATTR_NAME_FIREFLIER XATTR_SECURITY_PREFIX XATTR_FIREFLIER_SUFFIX
+
+
+/* module stacking operations */
+/**
+ * fireflier_register_security - register a stacked security module
+ * @name: the name of the secondary security module to register
+ * @ops:  the stacked module's security_operations 
+ */
+static int fireflier_register_security (const char *name, struct 
security_operations *ops)
+{
+        if (secondary_ops != original_ops)
+        {
+                printk(KERN_INFO "%s:  There is already a secondary 
security "
+                       "module registered.\n", __FUNCTION__);
+                return -EINVAL;
+        }
+	
+        secondary_ops = ops;
+	
+        printk(KERN_INFO "%s:  Registering secondary module %s\n",
+               __FUNCTION__,
+               name);
+
+        return 0;
+}
+
+/**
+ * fireflier_unregister_security - unregister a stacked security 
+ * @name: the name of the secondary security module to unregister
+ * @ops:  the security_operations of the stacked module
+ */
+static int fireflier_unregister_security (const char *name, struct 
security_operations *ops)
+{
+        if (ops != secondary_ops)
+        {
+                printk (KERN_INFO "%s:  trying to unregister a security 
module "
+                        "that is not registered.\n", __FUNCTION__);
+                return -EINVAL;
+        }
+
+        secondary_ops = original_ops;
+
+        return 0;
+}
+
+
+/**
+ * task_alloc_security - allocate the security structure for a task
+ * @task: the task to allocate the security structure for
+ * Allocates and initializes the security structure of a task.
+ * Returns -ENOMEM in case of an allocation failure.
+ * This function might sleep.
+ */
+static int task_alloc_security(struct task_struct *task)
+{
+	struct fireflier_task_security_struct *tsec;
+	
+	tsec = kzalloc(sizeof(*tsec), GFP_KERNEL);
+	if (!tsec)
+		return -ENOMEM;
+	
+
+	tsec->task = task;
+	tsec->osid = tsec->sid = tsec->ptrace_sid = FIREFLIER_SID_UNLABELED;
+	task->security = tsec;
+	
+	return 0;
+}
+
+/**
+ * task_free_security - free the security structure of a task
+ */
+static void task_free_security(struct task_struct *task)
+{
+	struct fireflier_task_security_struct *tsec = task->security;
+	
+	if (!tsec)
+		return;
+	
+	task->security = NULL;
+	kfree(tsec);
+}
+
+/**
+ * fireflier_task_alloc_security - allocate & initialize the security 
structure of tsk from current
+ * @tsk: the task who's security context needs to be initialized
+ * In case of allocation failure returns -ENOMEM
+ * otherwise calls secondary security module.
+ * Might sleep.
+ */
+static int fireflier_task_alloc_security(struct task_struct *tsk)
+{
+	struct fireflier_task_security_struct *tsec_current, *tsec_tsk;
+
+
+	int rc;
+	rc = task_alloc_security(tsk);
+	if (rc)
+		return rc;
+	tsec_current = current->security;
+	if(tsec_current) {
+		tsec_tsk = tsk->security;
+
+		tsec_tsk->sid = tsec_current->sid;
+		tsec_tsk->osid = tsec_current->osid;
+		/* Retain ptracer SID across fork, if any.
+		   This will be reset by the ptrace hook upon any
+		   subsequent ptrace_attach operations. */
+		tsec_tsk->ptrace_sid = tsec_current->ptrace_sid;
+	}
+	//else printk(KERN_DEBUG "current has no security info\n");
+	return 0;
+}
+
+
+/**
+ * fireflier_bprm_alloc_security - allocate & initialize a linux_bprm 
structure
+ * @bprm: the linux_bprm structure to initialize
+ * Returns -ENOMEM on allocation failure, otherwise calls stacked security 
module.
+ * Might sleep.
+ */
+static int fireflier_bprm_alloc_security(struct linux_binprm *bprm)
+{
+	struct fireflier_bprm_security_struct *bsec;
+
+	bsec = kzalloc(sizeof(*bsec), GFP_KERNEL);
+	if (!bsec)
+		return -ENOMEM;
+
+
+	bsec->bprm = bprm;
+	bsec->sid = FIREFLIER_SID_UNLABELED;
+	bsec->set = 0;
+
+	bprm->security = bsec;
+	
+	return 0;
+}
+
+/**
+ * fireflier_bprm_set_security - Sets the SID of bprm
+ * @bprm: linux_bprm structure, its SID will be calculated here
+ * This is where the (autolabeling) sid generation function is called, i.e.
+ * this function is responsible for computing the SID of the process that is 
going to be executed
+ * Calls secondary security module.
+ * Can this sleep?
+ */
+static int fireflier_bprm_set_security(struct linux_binprm *bprm)
+{
+	struct fireflier_bprm_security_struct *bsec;
+
+	bsec = bprm->security;		
+	if (bsec->set)
+		return  secondary_ops->bprm_set_security(bprm);
+
+	bsec->sid = get_or_generate_sid(bprm->file,0);
+        printk(KERN_DEBUG "sid:%d\n",bsec->sid);
+	bsec->set = 1;
+	return  secondary_ops->bprm_set_security(bprm);
+}
+
+/**
+ * fireflier_bprm_free_security - free the binbprm's security structure
+ * @bprm: linux_binprm structure, who's security structure is to be freed
+ */
+static void fireflier_bprm_free_security(struct linux_binprm *bprm)
+{
+	kfree(bprm->security);
+	bprm->security = NULL;
+}
+
+/**
+ * fireflier_bprm_apply_creds - compute the sid of the current task based on 
bprm
+ * @bprm: linux_binprm structure
+ * @unsafe: reasons why the transition might be unsafe
+ * Compute the sid of a process being transformed by an execve operation
+ */
+static void fireflier_bprm_apply_creds(struct linux_binprm *bprm, int unsafe)
+{
+	struct fireflier_task_security_struct *tsec;
+	struct fireflier_bprm_security_struct *bsec;
+	u32 sid;
+
+
+	secondary_ops->bprm_apply_creds(bprm, unsafe);
+
+	tsec = current->security;
+	bsec = bprm->security;
+	sid = bsec->sid;
+
+
+	bsec->unsafe = 0;
+	if (tsec->sid != sid) {
+		/* hmmm unsafe&ptrace stuff.... need to think over this a bit*/
+		if(unsafe & (LSM_UNSAFE_SHARE | LSM_UNSAFE_PTRACE|LSM_UNSAFE_PTRACE_CAP)) 
+		{	   
+		
+			printk(KERN_DEBUG "marking SID as unsafe\n");
+			bsec->unsafe=unsafe;
+		}
+	   
+		tsec->sid = sid;
+	}	
+}
+
+
+/**
+ * inode_update_perm - update the group SID of this inode
+ * @tsk - the task that has accesses the inode
+ * @inode - the inode who's SID has to be updated
+ * A task has accessed this file, add the task's SID to the group SID of 
tasks
+ * accessing the file
+ * based on inode_has_perm 
+ */
+static void inode_update_perm(struct task_struct *tsk,struct inode *inode)
+{
+	struct fireflier_task_security_struct *tsec;
+	struct fireflier_inode_security_struct *isec;
+        u32 sid;
+   
+     	tsec = tsk->security;
+   	isec = inode->i_security;
+   	if(!isec) 
+     		return;
+   
+        if(unlikely(!tsec))
+       		sid = compute_inode_sid(isec->sid,FIREFLIER_SID_UNLABELED);
+   	else
+     		sid = compute_inode_sid(isec->sid,tsec->sid);
+        spin_lock(&isec->sid_lock);
+        isec->sid=sid;     
+        spin_unlock(&isec->sid_lock);
+         	
+	printk(KERN_DEBUG "computed inode sid: %ld->%d\n",inode->i_ino,isec->sid);   
+}
+
+
+
+/** 
+ * file_update_perm - update the group SID of this file
+ * @tsk - the task that has accessed the file
+ * @file - the file that has been accessed
+ * A task has accessed this file, add the task's SID to the group SID of 
tasks
+ * accessing the file
+ * Based on file_has_perm 
+ */
+static  inline void file_update_perm(struct task_struct *tsk, struct file 
*file)    
+{
+	inode_update_perm(tsk, file->f_dentry->d_inode);
+}
+
+
+  
+ 
+/** 
+ * update_files_auth - update the group SID of the files
+ * @files - a files_struct containing all files of the forked process
+ * Derived from fs/exec.c:flush_old_files. 
+ *  Should deal only with sockets 
+ */
+static inline void update_files_auth(struct files_struct * files)  
+{
+   
+   
+	struct file *file;
+	struct fdtable *fdt;
+	long j = -1;
+  
+	/* Revalidate access to inherited open files. */
+	spin_lock(&files->file_lock);
+	for (;;) 
+	{
+		unsigned long set, i;
+	
+		j++;
+		i = j * __NFDBITS;
+		fdt = files_fdtable(files);
+		if (i >= fdt->max_fds || i >= fdt->max_fdset)
+			break;
+		set = fdt->open_fds->fds_bits[j];
+		if (!set)
+			continue;
+		spin_unlock(&files->file_lock);
+		for ( ; set ; i++,set >>= 1) 
+		{
+			if (set & 1) 
+			{
+				file = fget(i);
+				if (!file)
+					continue;
+				file_update_perm(current,file);
+				fput(file);
+			}
+		}
+		spin_lock(&files->file_lock);
+	}
+	spin_unlock(&files->file_lock);
+}
+
+	 
+/**
+ * fireflier_bprm_post_apply_creds - updates files' SID
+ * @bprm - a linux_bprm structure
+ * update the security field of bprm
+ */
+static void fireflier_bprm_post_apply_creds(struct linux_binprm *bprm)
+{
+	struct fireflier_task_security_struct *tsec = current->security;
+	struct fireflier_bprm_security_struct *bsec  = bprm->security;
+	secondary_ops->bprm_post_apply_creds(bprm);
+	
+	if(bsec->unsafe) 
+	{
+	
+		printk(KERN_DEBUG "computing unsafe SID\n");
+		tsec->sid = get_or_generate_unsafe_sid(tsec->sid,bsec->unsafe);
+	
+	}
+   
+	ff_debug_map_pidsid(tsec->sid);
+	if (tsec->osid == tsec->sid)
+		return;
+   	//SID changed, so update the files's SIDs, i.e. turn them into group SIDs
+	update_files_auth(current->files);
+}
+
+/**
+ * fireflier_inode_alloc_security - allocate the security structure of an 
inode
+ * @inode - inode
+ * allocate the security field of inode
+ */
+static int inode_alloc_security(struct inode *inode)
+{
+	struct fireflier_task_security_struct *tsec = current->security;
+	struct fireflier_inode_security_struct *isec;
+	     
+	isec = kzalloc(sizeof(struct fireflier_inode_security_struct), GFP_KERNEL);
+	if (!isec)
+		return -ENOMEM;
+	     
+	isec->inode = inode;
+	//isec->sclass = SECCLASS_FILE;
+	if (tsec)
+		isec->sid = tsec->sid;
+	else
+		isec->sid = FIREFLIER_SID_UNLABELED;
+        spin_lock_init(&isec->sid_lock);
+	inode->i_security = isec;
+	return 0;
+}
+	
+/**
+ * fireflier_inode_free_security - free the security structure of the inode
+ * @inode - inode
+ * free the security field of inode
+ */
+static void fireflier_inode_free_security(struct inode *inode)
+{
+	struct fireflier_inode_security_struct *isec = inode->i_security;
+//	struct fireflier_superblock_security_struct *sbsec = 
inode->i_sb->s_security;
+	     
+	if (!isec)// || !sbsec)
+		return;
+	     
+	inode->i_security = NULL;
+	kfree(isec);
+}
+
+static int fireflier_socket_accept(struct socket *sock, struct socket 
*newsock)
+{
+	struct fireflier_inode_security_struct *isec = SOCK_INODE(sock)->i_security;        
+        struct inode* newinode = SOCK_INODE(newsock);
+	struct fireflier_inode_security_struct *newisec;
+   
+        inode_alloc_security(newinode);
+   
+        newisec = newinode->i_security;    
+        spin_lock(&isec->sid_lock);
+        newisec->sid = isec->sid;
+        spin_unlock(&isec->sid_lock);
+   
+	return secondary_ops->socket_accept(sock,newsock);
+}
+	
+/** fireflier_file_receive - file received (via SysV IPC?)
+ * update group SID of file
+ */
+
+static int fireflier_file_receive(struct file* file)
+{
+	file_update_perm(current,file);
+	return secondary_ops->file_receive(file);
+}
+
+/*
+ * Copy the in-core inode security context value to the user.  If the
+ * getxattr() prior to this succeeded, check to see if we need to
+ * canonicalize the value to be finally returned to the user.
+ *
+ * Permission check is handled by selinux_inode_getxattr hook.
+ */
+static int fireflier_inode_getsecurity(struct inode *inode, const char *name, 
void *buffer, size_t size, int err)
+{
+	struct fireflier_inode_security_struct *isec = inode->i_security;
+	char *context=NULL;/* required!*/
+	unsigned len;
+	int rc;
+
+	if (strcmp(name, XATTR_FIREFLIER_SUFFIX) || !isec) {
+		rc = -EOPNOTSUPP;
+		goto out;
+	}
+     
+	rc = fireflier_sid_to_context(isec->sid, &context, &len);
+	if (rc)
+		goto out;
+
+	/* Probe for required buffer size */
+	if (!buffer || !size) {
+		rc = len;
+		goto out_free;
+	}
+
+	if (size < len) {
+		rc = -ERANGE;
+		goto out_free;
+	}
+
+	memcpy(buffer, context, len);
+	rc = len;
+ out_free:
+	kfree(context);
+ out:
+        return 0;
+}
+
+static int fireflier_inode_listsecurity(struct inode *inode, char *buffer, 
size_t buffer_size)
+{
+	if(inode->i_security) 
+	{
+	
+		const int len = sizeof(XATTR_NAME_FIREFLIER);
+		if (buffer && len <= buffer_size)
+			memcpy(buffer, XATTR_NAME_FIREFLIER, len);
+		return len;
+	}
+	else 
+		return 0;
+   
+
+}
+
+static void fireflier_socket_post_create(struct socket *sock, int family,
+					 int type, int protocol, int kern)
+{
+	struct fireflier_inode_security_struct *isec;
+	struct fireflier_task_security_struct *tsec = current->security;
+        struct inode* inode=SOCK_INODE(sock);
+   
+	secondary_ops->socket_post_create(sock,family,type,protocol,kern);
+	
+        inode_alloc_security(inode);
+	isec = inode->i_security;
+   
+        spin_lock(&isec->sid_lock);
+	isec->sid = kern ? FIREFLIER_SECINITSID_KERNEL : tsec->sid;
+        spin_unlock(&isec->sid_lock);
+   
+	return;
+}
+
+/**
+ * fireflier_ops - our security_operations hooks
+ * Unused security hooks will be automatically redirected to the dummy 
security module
+ * Does the dummy module call the secondary module? Maybe we should implement 
all the hooks, and call
+ * the secondary module
+ */
+static struct security_operations fireflier_ops =
+{
+	.bprm_alloc_security  	= fireflier_bprm_alloc_security,
+	.bprm_free_security  	= fireflier_bprm_free_security,
+	.bprm_apply_creds  	= fireflier_bprm_apply_creds,
+	.bprm_post_apply_creds  = fireflier_bprm_post_apply_creds,
+	.bprm_set_security 	= fireflier_bprm_set_security,
+	.inode_free_security 	= fireflier_inode_free_security,
+    	.inode_getsecurity 	= fireflier_inode_getsecurity,
+   	.inode_listsecurity 	= fireflier_inode_listsecurity,
+	.file_receive 		= fireflier_file_receive,
+	.task_alloc_security 	= fireflier_task_alloc_security,
+	.task_free_security 	= task_free_security,
+	.socket_post_create 	= fireflier_socket_post_create,
+	.socket_accept 		= fireflier_socket_accept,
+	.register_security 	= fireflier_register_security,
+	.unregister_security 	= fireflier_unregister_security,
+};
+
+/**
+ * stacked - is a secondary module registered
+ */
+static int stacked=0;
+
+/**
+ * label_all_processes - labels already running processes
+ * Can this be done at all? Or do we need to have fireflier loaded during 
boot?
+ */
+static void label_all_processes(void)
+{
+	/* Labeling running processes without using the task_lock seems not possible 
for now*/
+        /* TODO: label processes that are already running */
+        /* TODO: prevent processes from being spawned while we label the 
running ones */
+	/* TODO Priority:Low, it works without this too */
+}
+
+/**
+ * fireflier_cleanup - Cleans up fireflier module
+ * Unregisters security module
+ */
+static void __exit fireflier_cleanup(void)
+{
+	if(stacked) {
+		if(mod_unreg_security("fireflier",&fireflier_ops))
+			printk(KERN_ERR "Fireflier: Error unregistering stacked security module.
\n");
+	}
+	else
+		if(unregister_security(&fireflier_ops))
+			printk(KERN_ERR "Fireflier: Error unregistering security module.\n");
+}
+
+int ff_debug;
+module_param(ff_debug,int,0);
+MODULE_PARM_DESC(ff_debug,"Enable debug info dumping in debugfs");
+/**
+ * fireflier_init - module loading initialization
+ * Registers fireflier as primary or secondary security module
+ */
+static int __init fireflier_init(void)
+{
+        /*Register security_ops with kernel*/
+        int err;
+
+        original_ops = security_ops;
+        /* initialize dummy_security_ops to dummy ops */
+        register_security(&dummy_security_ops);
+        unregister_security(&dummy_security_ops);
+        secondary_ops = &dummy_security_ops;//avoid recursion with capability 
module
+        if (!secondary_ops) {
+                printk (KERN_ERR "Fireflier: No initial security 
operations\n");
+                return -EAGAIN;
+        }
+        if ((err=register_security (&fireflier_ops))) {
+                printk(KERN_INFO "Fireflier: Unable to register as primary 
security module. Attempting to register as stacked security module\n");
+                stacked=1;
+                if((err=mod_reg_security("fireflier",&fireflier_ops))) {
+                        printk(KERN_ERR "Fireflier: Unable to register with 
kernel.\n");
+                        return err;
+                }
+        }
+        else
+                stacked=0;
+        /* Do initialization */
+	if((err=autolabel_init())) {
+		printk(KERN_ERR "Fireflier: autolabeling initialization failed (OOM?)\n");
+		fireflier_cleanup();
+		return err;
+	}
+        label_all_processes();
+	
+	/* Debugging stuff */
+	ff_debug_startup();
+	
+        return 0;
+}
+
+security_initcall(fireflier_init);
+module_exit(fireflier_cleanup);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Török Edwin <edwin@gurde.com>");
+MODULE_DESCRIPTION("Fireflier security module");
+MODULE_VERSION("0.01");
+
diff -uprN null/structures.h fireflier_lsm/structures.h
--- null/structures.h	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/structures.h	2006-04-14 22:48:13.000000000 +0300
@@ -0,0 +1,62 @@
+/*
+ *  Fireflier security labeling module
+ *
+ *
+ *  This file contains the Fireflier hook function implementations.
+ *
+ *  Based on the SELinux hooks.c
+ *
+ *  Copyright (C) 2006 Török Edwin <edwin@gurde.com>
+ *
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *	it under the terms of the GNU General Public License version 2,
+ *      as published by the Free Software Foundation.
+ */
+#ifndef _FF_STRUCTURES_H_
+#define _FF_STRUCTURES_H_
+#include <linux/list.h>
+#include <linux/spinlock.h>
+#include "constants.h"
+/* Structures copied from SELinux, and prefixed with fireflier_ to avoid 
conflicts
+ * I don't want to use SELinux internal structures.
+ */ 
+ 
+ 
+struct fireflier_task_security_struct {
+	struct task_struct *task;      /* back pointer to task object */
+	u32 sid;             /* current SID */
+	u32 osid;	     /* SID prior to execve */
+	u32 ptrace_sid;      /* SID of ptrace parent */
+};
+
+struct fireflier_inode_security_struct {
+	struct inode *inode;           /* back pointer to inode object */
+        spinlock_t sid_lock;
+	u32 sid;             /* SID of this object */
+};
+
+struct fireflier_bprm_security_struct {
+	struct linux_binprm *bprm;     /* back pointer to bprm object */
+	u32 sid;                       /* SID for transformed process */
+	unsigned char set;
+
+	/*
+	 * unsafe is used to share failure information from bprm_apply_creds()
+	 * to bprm_post_apply_creds().
+	 */
+	char unsafe;
+};
+/**
+ * getsid_safe - returns the SID, safe to be called with a  NULL pointer
+ * @tsec: a task's security structure to get the SID from, it can be NULL
+ */
+static inline u32 getsid_safe(const struct fireflier_task_security_struct* 
tsec)
+{
+	if(likely(tsec))
+		return tsec->sid;
+	else
+		return FIREFLIER_SID_UNLABELED;
+}
+
+#endif

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Fri, 2006-04-14 at 23:01 +0300, Török Edwin wrote:
> Would there be a reason to implement floating labels in SELinux?

Unclear.  CMWs and the Posix.1e draft had floating information labels,
but they were separate from the access control label.  So if implemented
in SELinux, they would be a separate field of the incore security
structures and, if required to persist, they would be a separate xattr
name/value pair.  They wouldn't be used for access control checking by
SELinux internally.  One would have to define the meaning of floating
for TE (or your scheme), as they aren't hierarchical.  Traditional
hierarchical floating labels track reads and writes, e.g. process
information label floats up upon reads to dominate the information label
of the object, and the object information label floats up upon writes to
dominate the information label of the writing process, so that if P
copies from object A to object B, object B ends up with an information
label at least as high as object A.  Whether or not this is useful has
been a subject of debate.

> How can I substitute floating labels (i.e. what would be its closest 
> approximation)?

Ideally, you would just predefine your control requirements, as below,
and enforce that via SELinux policy rather than trying to separately
track the data flow via LSM and enforce some kind of restriction via
your userspace component+netfilter module.  Also see the Security
marking RFC posted by James Morris to netdev.

> Functional requirement:
> - be able to control/know which programs have access to the internet
> - be able to control/know which processes have access to a certain socket
> - be able to control/know which processes share a socket, and which processes 
> are the only ones accessing a socket
> 
> I used the term 'control/know', because I don't actually want to restrict the 
> applications by using fireflier lsm, I just want it to provide information to 
> its userspace part.

Hmmm...well, the control requirements above can be met by SELinux, just
not in the manner you are trying to meet them, as SELinux already labels
and controls use of sockets and access to ports, nodes (hosts), and
network interfaces.

> -- plan for fireflier SELinux integration (fireflier target version 2.1)---
> 
> Possible approaches I thought of:
> 1)  put programs needing to share a socket in the same domain, and match based 
> on the domain of the socket. But what happens if a program would need to be 
> in 2  or more domains (xinetd comes to mind)

The processes don't have to be in the same domain to share the socket;
SELinux policy already allows you to permit one domain to
inherit/receive and use sockets created by another domain if so
configured.  

> But a problem remains: if there is a base policy that sets a context on a 
> program, and  my module would try to set a domain for it too, won't they 
> conflict?

You could extend the definition of the existing domain via your module
if that fits your needs.  As the base policy becomes more modularized,
you could replace the particular module entirely with your own if that
is necessary.

> 2) each program has its own domain, and xinetd is in a domain of its own, but 
> it has access to all the sockets of its childs (domains). The same for 
> postfix
> Also run selinux in non-enforcing mode, with avc logging turned off. I only 
> need labeling, not restrictions.

But you do need restrictions (on network access); you just want to
implement them yourself for some reason rather than using the existing
SELinux controls.  Not clear why.

> 3)Or should I assume, that if a user has a base policy set up, he has 
> configured that properly, and only those programs share sockets, that he 
> intends to?
> In this case fireflier would need to do only this:
> - if selinux is disabled, then run a policy generator, that generates a base 
> policy (not necessarely a module). fireflier will make sure user runs with 
> selinux enabled, avc logging off, enforcing off
> - if selinux is enabled, fireflier won't do shared socket checks, assuming 
> that the policy will limit the sharing of sockets

Depends on whether you want your tool to continue to be useful for
systems using SELinux.

> Important question: can a file's context be set from the policy? 
> (without using setfiles, to relabel the file, the user might want to enable 
> selinux later, I don't want to mess up his labeling)
> (this might sound silly: can a define a default auto-transition to a context?)

Certain defaults are provided from policy, but the per-file labeling
comes from the xattrs.  Newly created files are assigned an initial
label by the kernel (both incore and xattr) based on policy by default,
or optionally overridden by application request (still subject to policy
control).

> To have all tasks assigned a security structure, fireflier lsm needs to be 
> compiled into the kernel.

Yes.  So?

> I thought of this, see label_all_processes. Unfortunately I found no way of 
> actually doing this. I would need to iterate through the tasklist structure, 
> but the task_lock export is going to be removed from the kernel.

So, if built-in isn't an option, propose an interface to the core
security framework to allow security modules to perform such
initialization without needing to directly touch the lock themselves
(i.e. they just call the function provided by the security framework,
and let it deal with taking the lock if that is appropriate).  Not the
same as exporting the lock directly to all modules for arbitrary misuse.

> Locking added. I use a lock every time the inode's sid is modified.

Except that your lock does no good.  See below.

> diff -uprN null/hooks.c fireflier_lsm/hooks.c
> --- null/hooks.c	1970-01-01 02:00:00.000000000 +0200
> +++ fireflier_lsm/hooks.c	2006-04-14 22:53:40.000000000 +0300

> +static void inode_update_perm(struct task_struct *tsk,struct inode *inode)
> +{
> +	struct fireflier_task_security_struct *tsec;
> +	struct fireflier_inode_security_struct *isec;
> +        u32 sid;
> +   
> +     	tsec = tsk->security;
> +   	isec = inode->i_security;
> +   	if(!isec) 
> +     		return;
> +   
> +        if(unlikely(!tsec))
> +       		sid = compute_inode_sid(isec->sid,FIREFLIER_SID_UNLABELED);
> +   	else
> +     		sid = compute_inode_sid(isec->sid,tsec->sid);
> +        spin_lock(&isec->sid_lock);
> +        isec->sid=sid;     
> +        spin_unlock(&isec->sid_lock);

The above locking is useless.
T1:	sid = compute_inode_sid(isec->sid, tsec->sid)
T2: 	sid = compute_inode_sid(isec->sid, tsec->sid)
T1:	lock; isec->sid = sid; unlock
T2:	lock; isec->sid = sid; unlock
You lose T1's information that way.

> +static void fireflier_socket_post_create(struct socket *sock, int family,
> +					 int type, int protocol, int kern)
> +{
> +	struct fireflier_inode_security_struct *isec;
> +	struct fireflier_task_security_struct *tsec = current->security;
> +        struct inode* inode=SOCK_INODE(sock);
> +   
> +	secondary_ops->socket_post_create(sock,family,type,protocol,kern);
> +	
> +        inode_alloc_security(inode);
> +	isec = inode->i_security;
> +   
> +        spin_lock(&isec->sid_lock);
> +	isec->sid = kern ? FIREFLIER_SECINITSID_KERNEL : tsec->sid;
> +        spin_unlock(&isec->sid_lock);

Shouldn't be necessary here, right, as the socket isn't yet accessible
to any other thread?  Likewise for the accept case?  Only when you are
mutating it after it becomes accessible to userspace.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Christoph Hellwig]

On Mon, Apr 17, 2006 at 12:06:53PM -0400, Stephen Smalley wrote:
> > I thought of this, see label_all_processes. Unfortunately I found no way of 
> > actually doing this. I would need to iterate through the tasklist structure, 
> > but the task_lock export is going to be removed from the kernel.
> 
> So, if built-in isn't an option, propose an interface to the core
> security framework to allow security modules to perform such
> initialization without needing to directly touch the lock themselves

NACK.  The whole idea of loading security modules after bootup is flawed.
Any scheme that tries to enumerate process and other entinity after the
fact for access control purposes is fundamentally flawed.  We're not going
to add helpers or exports for it, I'd rather remove the ability to build
lsm hook clients modular completely.

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Mon, 2006-04-17 at 17:23 +0100, Christoph Hellwig wrote:
> On Mon, Apr 17, 2006 at 12:06:53PM -0400, Stephen Smalley wrote:
> > > I thought of this, see label_all_processes. Unfortunately I found no way of 
> > > actually doing this. I would need to iterate through the tasklist structure, 
> > > but the task_lock export is going to be removed from the kernel.
> > 
> > So, if built-in isn't an option, propose an interface to the core
> > security framework to allow security modules to perform such
> > initialization without needing to directly touch the lock themselves
> 
> NACK.  The whole idea of loading security modules after bootup is flawed.
> Any scheme that tries to enumerate process and other entinity after the
> fact for access control purposes is fundamentally flawed.  We're not going
> to add helpers or exports for it, I'd rather remove the ability to build
> lsm hook clients modular completely.

Or, better, remove LSM itself ;)

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Arjan van de Ven]

On Mon, 2006-04-17 at 13:03 -0400, Stephen Smalley wrote:
> On Mon, 2006-04-17 at 17:23 +0100, Christoph Hellwig wrote:
> > On Mon, Apr 17, 2006 at 12:06:53PM -0400, Stephen Smalley wrote:
> > > > I thought of this, see label_all_processes. Unfortunately I found no way of 
> > > > actually doing this. I would need to iterate through the tasklist structure, 
> > > > but the task_lock export is going to be removed from the kernel.
> > > 
> > > So, if built-in isn't an option, propose an interface to the core
> > > security framework to allow security modules to perform such
> > > initialization without needing to directly touch the lock themselves
> > 
> > NACK.  The whole idea of loading security modules after bootup is flawed.
> > Any scheme that tries to enumerate process and other entinity after the
> > fact for access control purposes is fundamentally flawed.  We're not going
> > to add helpers or exports for it, I'd rather remove the ability to build
> > lsm hook clients modular completely.
> 
> Or, better, remove LSM itself ;)
> 

at minimum I can see the point to make the lsm hooks compile directly to
the selinux functions in question when selinux is the security module of
choice; that'll save quite a bit of performance already

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Christoph Hellwig]

On Mon, Apr 17, 2006 at 01:03:24PM -0400, Stephen Smalley wrote:
> > fact for access control purposes is fundamentally flawed.  We're not going
> > to add helpers or exports for it, I'd rather remove the ability to build
> > lsm hook clients modular completely.
> 
> Or, better, remove LSM itself ;)

Seriously that makes a lot of sense.  All other modules people have come up
with over the last years are irrelevant and/or broken by design.

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Casey Schaufler]

--- Christoph Hellwig <hch@infradead.org> wrote:

> > Or, better, remove LSM itself ;)
> 
> Seriously that makes a lot of sense.  All other
> modules people have come up
> with over the last years are irrelevant and/or
> broken by design.

Didn't you mean "Bah!" (waves paw)?

I understand the enthusiasm that the SELinux
following demonstrates for the technology.
I do not appreciate the bashing of alternatives.


Casey Schaufler
casey@schaufler-ca.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Mon, 2006-04-17 at 11:02 -0700, Casey Schaufler wrote:
> 
> --- Christoph Hellwig <hch@infradead.org> wrote:
> 
> > > Or, better, remove LSM itself ;)
> > 
> > Seriously that makes a lot of sense.  All other
> > modules people have come up
> > with over the last years are irrelevant and/or
> > broken by design.
> 
> Didn't you mean "Bah!" (waves paw)?
> 
> I understand the enthusiasm that the SELinux
> following demonstrates for the technology.
> I do not appreciate the bashing of alternatives.

Then provide a counterexample.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Mon, 2006-04-17 at 11:02 -0700, Casey Schaufler wrote:
> > 
> > --- Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > > > Or, better, remove LSM itself ;)
> > > 
> > > Seriously that makes a lot of sense.  All other
> > > modules people have come up
> > > with over the last years are irrelevant and/or
> > > broken by design.
> > 
> > Didn't you mean "Bah!" (waves paw)?
> > 
> > I understand the enthusiasm that the SELinux
> > following demonstrates for the technology.
> > I do not appreciate the bashing of alternatives.
> 
> Then provide a counterexample.

Hopefully a new version of evm+slim+ima will be ready for distribution
soon.

-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[James Morris]

On Mon, 17 Apr 2006, Serge E. Hallyn wrote:

> Hopefully a new version of evm+slim+ima will be ready for distribution
> soon.

Why are you still trying to introduce yet another access control model 
into the kernel, when SELinux is already there?

Last I recall on this issue, we asked if you could look at providing 
integrity measurement as a distinct API, and integrity control as either 
integrated with SELinux or a distinct component which SELinux could use.



- James
-- 
James Morris
<jmorris@namei.org>

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting James Morris (jmorris@namei.org):
> On Mon, 17 Apr 2006, Serge E. Hallyn wrote:
> 
> > Hopefully a new version of evm+slim+ima will be ready for distribution
> > soon.
> 
> Why are you still trying to introduce yet another access control model 
> into the kernel, when SELinux is already there?

Well actually I'm really not much involved.

> Last I recall on this issue, we asked if you could look at providing 
> integrity measurement as a distinct API, and integrity control as either 
> integrated with SELinux or a distinct component which SELinux could use.

And those are what I believe the next patchset will provide.

-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Mon, 2006-04-17 at 14:47 -0500, Serge E. Hallyn wrote:
> Quoting James Morris (jmorris@namei.org):
> > Last I recall on this issue, we asked if you could look at providing 
> > integrity measurement as a distinct API, and integrity control as either 
> > integrated with SELinux or a distinct component which SELinux could use.
> 
> And those are what I believe the next patchset will provide.

At the conclusion of the last round of discussions on slim-evm-ima on
list, it was the case that:
- ima was no longer an issue, as it had already ceased being a separate
LSM,
- it was demonstrated that evm needed to be tightly coupled with any LSM
in order to work correctly and efficiently, and it seemed to be accepted
that evm needed to be turned from a separate LSM into a set of support
functions for use by a LSM (as well as having many other design and
implementation problems to resolve to be truly useable),
- it was argued that slim was broken-by-design and no one was willing or
able to refute that position.

Hardly a strong case for LSM...

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[David Safford]

On Mon, 2006-04-17 at 16:02 -0400, Stephen Smalley wrote: 
> At the conclusion of the last round of discussions on slim-evm-ima on
> list, it was the case that:

> ima was no longer an issue, as it had already ceased being a separate
> LSM,

Agreed. Integrity attestation clearly needed to be tightly coupled with
integrity measurement.

> it was demonstrated that evm needed to be tightly coupled with any LSM
> in order to work correctly and efficiently, and it seemed to be accepted
> that evm needed to be turned from a separate LSM into a set of support
> functions for use by a LSM (as well as having many other design and
> implementation problems to resolve to be truly useable),

It was certainly agreed that integrity needed to be a separate service
available to any access control module, with nothing specific to SLIM, 
and that a number of design and implementation problems had to be fixed. 
During testing we also found a number of other bugs which weren't raised 
on the list, which had to be fixed. (That's what has taken us so long to 
post a new version.) As to whether it should be tightly coupled to an
LSM module, or should be a separate service with its own kernel hooks,
I think was not settled. 

> - it was argued that slim was broken-by-design and no one was willing or
> able to refute that position.
> 
> Hardly a strong case for LSM...

I seem to recall a number of people arguing for the low water-mark 
integrity policy as one which provides a simple, user friendly 
policy, one which has been demonstrated and tested not only by
SLIM, but also with predecessors, such as LOMAC. 

I do understand and respect the selinux position against dynamic 
labels, since they require revocation, and particularly since at 
that time, we had not implemented revocation of mmap access. We 
have been quietly studying, fixing, and testing the design and
implementation errors pointed out earlier, and still feel strongly 
that low water-mark policies have a place, particularly in client
systems. 

Since selinux (by choice) cannot implement policies with dynamic labels,
I believe LSM is important for work in alternative access control
models, like low water-mark, to continue.

dave safford

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Wed, 2006-04-19 at 10:52 -0400, David Safford wrote:
> It was certainly agreed that integrity needed to be a separate service
> available to any access control module, with nothing specific to SLIM, 
> and that a number of design and implementation problems had to be fixed. 
> During testing we also found a number of other bugs which weren't raised 
> on the list, which had to be fixed. (That's what has taken us so long to 
> post a new version.) As to whether it should be tightly coupled to an
> LSM module, or should be a separate service with its own kernel hooks,
> I think was not settled. 

Ok, either way removal of LSM isn't an issue in that case.

> I seem to recall a number of people arguing for the low water-mark 
> integrity policy as one which provides a simple, user friendly 
> policy, one which has been demonstrated and tested not only by
> SLIM, but also with predecessors, such as LOMAC. 
> 
> I do understand and respect the selinux position against dynamic 
> labels, since they require revocation, and particularly since at 
> that time, we had not implemented revocation of mmap access. We 
> have been quietly studying, fixing, and testing the design and
> implementation errors pointed out earlier, and still feel strongly 
> that low water-mark policies have a place, particularly in client
> systems. 

My concerns with low water mark were noted in
http://marc.theaimsgroup.com/?l=linux-security-module&m=113232319627338&w=2
http://marc.theaimsgroup.com/?l=linux-security-module&m=113319033229209&w=2
http://marc.theaimsgroup.com/?l=linux-security-module&m=113327082228907&w=2

I also pointed out examples of how low water mark has
compatibility/useability problems of its own in that discussion.  And it
has only has the two options available to all such "simple" models when
reality conflicts with their model:  preserve the model and break the
functionality or make the process a trusted subject fully capable of
violating the model (at which point you are only pretending to enforce
the model).  Versus being able to configure the policy to match reality,
as in SELinux.

> Since selinux (by choice) cannot implement policies with dynamic labels,
> I believe LSM is important for work in alternative access control
> models, like low water-mark, to continue.

If such models can demonstrate their viability, then you can ultimately
submit a patch to extend SELinux/Flask to support them - I have no
problem with that (again, if they can be shown to be viable and
implementation is correct).  But first you have to show that.  In the
meantime, your work can be done via a kernel patch that you carry; it
doesn't justify keeping LSM in mainline.  Note too that LSM seems to me
to be harmful to such work, because many of the mistakes you made in the
first place might have been avoided if you had started by extending the
existing SELinux/Flask infrastructure (which had much more defined
semantics) than using LSM (which is just a skeletal framework with no
real semantics).  Plus it might have encouraged you to propose each
change as a small patch to SELinux along the way and gotten you valuable
feedback sooner.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Emily Ratliff]

On 4/19/06, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> BTW, since you point to LOMAC as evidence, can you point to an actual
> user community that uses LOMAC?
EVM & SLIM are part of IBM's internal supported Linux desktop, so
there are quite a few users.

> My concerns with low water mark were noted in
> http://marc.theaimsgroup.com/?l=linux-security-module&m=113232319627338&w=2
...
And Tim Fraser's and Dave Safford's responses are noted in
http://marc.theaimsgroup.com/?l=linux-security-module&m=113323166505015&w=2
http://marc.theaimsgroup.com/?l=linux-security-module&m=113337110408758&w=2
http://marc.theaimsgroup.com/?l=linux-security-module&m=113234278611701&w=2

> If such models can demonstrate their viability, then you can ultimately
> submit a patch to extend SELinux/Flask to support them - I have no
> problem with that (again, if they can be shown to be viable and
> implementation is correct).
Dave has an existing implementation with a user base of a formally
proven security model. He is addressing implementation concerns and
continuing to try to get SLIM accepted. Why should he be required to
extend SELinux?

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Wed, 2006-04-19 at 12:57 -0500, Emily Ratliff wrote:
> On 4/19/06, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > BTW, since you point to LOMAC as evidence, can you point to an actual
> > user community that uses LOMAC?
> EVM & SLIM are part of IBM's internal supported Linux desktop, so
> there are quite a few users.

Um, ok.  Not sure what that means in practice, but good to know you have
actual users.

> And Tim Fraser's and Dave Safford's responses are noted in
> http://marc.theaimsgroup.com/?l=linux-security-module&m=113323166505015&w=2
> http://marc.theaimsgroup.com/?l=linux-security-module&m=113337110408758&w=2
> http://marc.theaimsgroup.com/?l=linux-security-module&m=113234278611701&w=2

But AFAICS they didn't respond to my actual points, whereas I responded
to their points.  In the end, their argument seemed to degenerate to
"SLIM should be accepted because it differs from SELinux" or "embrace
diversity for diversity's sake."  Not entirely compelling.

> > If such models can demonstrate their viability, then you can ultimately
> > submit a patch to extend SELinux/Flask to support them - I have no
> > problem with that (again, if they can be shown to be viable and
> > implementation is correct).
> Dave has an existing implementation with a user base of a formally
> proven security model. He is addressing implementation concerns and
> continuing to try to get SLIM accepted. Why should he be required to
> extend SELinux?

Well, I haven't seen any new code submitted since last Nov, and the code
at that time was badly broken to the point that it seemed to require a
re-design, and none of the modules at the time appeared to justify LSM
or the stacker; if anything, they were a warning that the stacker and
LSM lend themselves to misuse, confusion, and broken code.

I'm sure we'd all be glad to see new patches.  But the issues that were
raised during the original discussion still need to be addressed.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Wed, 2006-04-19 at 14:33 -0400, Stephen Smalley wrote:
> On Wed, 2006-04-19 at 12:57 -0500, Emily Ratliff wrote:
> > Dave has an existing implementation with a user base of a formally
> > proven security model. He is addressing implementation concerns and
> > continuing to try to get SLIM accepted. Why should he be required to
> > extend SELinux?
> 
> Well, I haven't seen any new code submitted since last Nov, and the code
> at that time was badly broken to the point that it seemed to require a
> re-design, and none of the modules at the time appeared to justify LSM
> or the stacker; if anything, they were a warning that the stacker and
> LSM lend themselves to misuse, confusion, and broken code.
> 
> I'm sure we'd all be glad to see new patches.  But the issues that were
> raised during the original discussion still need to be addressed.

BTW, this isn't the first time that he has been encouraged to consider
extending SELinux rather than going it alone with his own custom LSM,
and the benefits to him would be:
- leveraging an existing code base and infrastructure that is already
upstream and included in several distros (including both the kernel code
as well as integration with userspace, policy tools, policy management
infrastructure, etc),
- being able to leverage the existing TE security model to complement
and fill in the gaps left by the low water mark model, just as it is
already being used to complement MLS,
- ensuring that the result integrates well and works well with SELinux,
for those who may want both low water mark and TE.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Wed, 2006-04-19 at 10:52 -0400, David Safford wrote:
> I seem to recall a number of people arguing for the low water-mark 
> integrity policy as one which provides a simple, user friendly 
> policy, one which has been demonstrated and tested not only by
> SLIM, but also with predecessors, such as LOMAC. 

BTW, since you point to LOMAC as evidence, can you point to an actual
user community that uses LOMAC?  It has been in the FreeBSD tree for
some time, so one might expect to find some users by now.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Gerrit Huizenga]

On Mon, 17 Apr 2006 15:31:08 EDT, James Morris wrote:
> On Mon, 17 Apr 2006, Serge E. Hallyn wrote:
> 
> > Hopefully a new version of evm+slim+ima will be ready for distribution
> > soon.
> 
> Why are you still trying to introduce yet another access control model 
> into the kernel, when SELinux is already there?

I get the impression from customers that SELinux is so painful to
configure correctly that most of them disable it.  In theory, LSM +
something like AppArmour provides a much simpler security model for
normal human beings who want some level of configuration.  Also,
the current SELinux config in RH is starting to have a measureable
performance impact.  I'm not sure this particular battle of the
security models is quite over from a real user perspective.

gerrit

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Alan Cox]

On Llu, 2006-04-17 at 15:15 -0700, Gerrit Huizenga wrote:
> I get the impression from customers that SELinux is so painful to
> configure correctly that most of them disable it.  In theory, LSM +

Red Hat ships SELinux enabled by default with a set of policies that
most users just leave enabled, indeed most users don't even know they
have SELinux enabled or what SELinux is, any more than they could say
tell you what posix acls do.

That said there is a need for nice pretty policy design tools, but
that's not part of an LSM discussion.

> something like AppArmour provides a much simpler security model for

If the AppArmour people care to submit their code upstream and get it
merged then that would be a reason to keep LSM, if they don't then LSM
(if they even want it..) can just become part of their patchkit instead.

> normal human beings who want some level of configuration.  Also,
> the current SELinux config in RH is starting to have a measureable
> performance impact. 

In Fedora Core its impact is far from obvious from my testing. Older
SELinux had some ugly SMP scaling problems but those are fixed.

Alan

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[James Morris]

On Mon, 17 Apr 2006, Alan Cox wrote:

> > something like AppArmour provides a much simpler security model for
> 
> If the AppArmour people care to submit their code upstream and get it
> merged then that would be a reason to keep LSM, if they don't then LSM
> (if they even want it..) can just become part of their patchkit instead.

This is the discussion we had a year ago, and have seen nothing 
upstream since.  I assume they do not intend to submit the code.



- James
-- 
James Morris
<jmorris@namei.org>

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Crispin Cowan]

Alan Cox wrote:
> On Llu, 2006-04-17 at 15:15 -0700, Gerrit Huizenga wrote:
>   
>> something like AppArmour provides a much simpler security model for
>>     
> If the AppArmour people care to submit their code upstream and get it
> merged then that would be a reason to keep LSM, if they don't then LSM
> (if they even want it..) can just become part of their patchkit instead.
>   
Indeed, this thread is timely.  We (SUSE) opensourced the user-level
AppArmor http://www.opensuse.org/AppArmor tools in January 2006
http://www.securityfocus.com/brief/103  and
http://lwn.net/Articles/166975/ and the kernel module has always been
open source.

We have been hard at work on making the code as CodingStyle-compliant as
we can since then, with the intent of submitting it for inclusion in the
kernel. We actually planned to submit it later this week, but in light
of this thread, we cut a few corners and expect to post our first
proposed patches here by about Wednesday.

Crispin
-- 
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Christoph Hellwig]

On Mon, Apr 17, 2006 at 03:15:29PM -0700, Gerrit Huizenga wrote:
> configure correctly that most of them disable it.  In theory, LSM +
> something like AppArmour provides a much simpler security model for

apparmor falls into the findamentally broken category above, so it's
totally uninteresting except as marketing candy for the big red company.

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Gerrit Huizenga]

On Mon, 17 Apr 2006 23:55:25 BST, Christoph Hellwig wrote:
> On Mon, Apr 17, 2006 at 03:15:29PM -0700, Gerrit Huizenga wrote:
> > configure correctly that most of them disable it.  In theory, LSM +
> > something like AppArmour provides a much simpler security model for
> 
> apparmor falls into the findamentally broken category above, so it's
> totally uninteresting except as marketing candy for the big red company.

Is there a pointer to why it is fundamentally broken?  I haven't seen
such comments before but it may be that I've been hanging out on the
wrong lists or spending too much time inhaling air at 30,000 feet.

gerrit

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Christoph Hellwig]

On Mon, Apr 17, 2006 at 06:44:51PM -0700, Gerrit Huizenga wrote:
> 
> On Mon, 17 Apr 2006 23:55:25 BST, Christoph Hellwig wrote:
> > On Mon, Apr 17, 2006 at 03:15:29PM -0700, Gerrit Huizenga wrote:
> > > configure correctly that most of them disable it.  In theory, LSM +
> > > something like AppArmour provides a much simpler security model for
> > 
> > apparmor falls into the findamentally broken category above, so it's
> > totally uninteresting except as marketing candy for the big red company.
> 
> Is there a pointer to why it is fundamentally broken?  I haven't seen
> such comments before but it may be that I've been hanging out on the
> wrong lists or spending too much time inhaling air at 30,000 feet.

It's doing access control on pathnames, which can't work in unix enviroments.
It's following the default permit behaviour which causes pain in anything
security-related (compare [1]).


[1] http://www.ranum.com/security/computer_security/editorials/dumb/

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Gerrit Huizenga]

On Tue, 18 Apr 2006 12:58:19 BST, Christoph Hellwig wrote:
> On Mon, Apr 17, 2006 at 06:44:51PM -0700, Gerrit Huizenga wrote:
> > 
> > On Mon, 17 Apr 2006 23:55:25 BST, Christoph Hellwig wrote:
> > > On Mon, Apr 17, 2006 at 03:15:29PM -0700, Gerrit Huizenga wrote:
> > > > configure correctly that most of them disable it.  In theory, LSM +
> > > > something like AppArmour provides a much simpler security model for
> > > 
> > > apparmor falls into the findamentally broken category above, so it's
> > > totally uninteresting except as marketing candy for the big red company.
> > 
> > Is there a pointer to why it is fundamentally broken?  I haven't seen
> > such comments before but it may be that I've been hanging out on the
> > wrong lists or spending too much time inhaling air at 30,000 feet.
> 
> It's doing access control on pathnames, which can't work in unix enviroments.
> It's following the default permit behaviour which causes pain in anything
> security-related (compare [1]).
> 
> 
> [1] http://www.ranum.com/security/computer_security/editorials/dumb/

Interesting but I'm not impressed by the article.  I think Stephen's
reference has a bit more meat to it.  According to this article my
laptop should set so I have a white list of apps (which would be
really really long, ergo why make a list?  I run much more than
5 apps on a day to day basis).  Even on a general purpose machine
that is shared by many users will have a large number of apps.  When
your white list is a large percentage of the apps that are on the
machine, these two approaches start to converge.  In the end it always
comes down to "how much security are you prepared to endure, given
that security almost always limits user capability".

Based on what this article says, it sounds like MACs and ACLs would be
required because without them they permit you to share data with people
that may not need that data, people should only have access to the
limited set of applications and data that they need, and the machine
should be tightened down to the point where the security approaches
absolute security.

While that might fit in with "perfect" security, most people aren't
interested in that level of perfection.  "Default permit" was so popular
because it caught the obvious exploits without overly limiting people's
ability to use a machine.  It is still pretty commonly used today.
Also, any security protection has a whole range of protections, from
firewalls, limiting which packages are installed, accounts/passwords,
validation of users, etc.  Does everyone have to have "perfect" security
or are there places where a "less than perfect, easy to use, good enough"
security policy?  I believe there is room for both based on the end
users' needs and desires.  But that is just my opinion.

gerrit

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Karl MacMillan]

On Tue, 2006-04-18 at 09:50 -0700, Gerrit Huizenga wrote:
> On Tue, 18 Apr 2006 12:58:19 BST, Christoph Hellwig wrote:
> > On Mon, Apr 17, 2006 at 06:44:51PM -0700, Gerrit Huizenga wrote:
> > > 
> > > On Mon, 17 Apr 2006 23:55:25 BST, Christoph Hellwig wrote:
> > > > On Mon, Apr 17, 2006 at 03:15:29PM -0700, Gerrit Huizenga wrote:
> > > > > configure correctly that most of them disable it.  In theory, LSM +
> > > > > something like AppArmour provides a much simpler security model for
> > > > 
> > > > apparmor falls into the findamentally broken category above, so it's
> > > > totally uninteresting except as marketing candy for the big red company.
> > > 
> > > Is there a pointer to why it is fundamentally broken?  I haven't seen
> > > such comments before but it may be that I've been hanging out on the
> > > wrong lists or spending too much time inhaling air at 30,000 feet.
> > 
> > It's doing access control on pathnames, which can't work in unix enviroments.
> > It's following the default permit behaviour which causes pain in anything
> > security-related (compare [1]).
> > 
> > 
> > [1] http://www.ranum.com/security/computer_security/editorials/dumb/
> 
> Interesting but I'm not impressed by the article.  I think Stephen's
> reference has a bit more meat to it.  According to this article my
> laptop should set so I have a white list of apps (which would be
> really really long, ergo why make a list?  I run much more than
> 5 apps on a day to day basis).  Even on a general purpose machine
> that is shared by many users will have a large number of apps.  When
> your white list is a large percentage of the apps that are on the
> machine, these two approaches start to converge.

Which is one reason why SELinux has types (equivalence classes) - it
makes it possible to group large numbers of applications or resources
into the same security category. The targeted policy that ships with
RHEL / Fedora shows how this works in practice.

Karl

-- 
Karl MacMillan
Tresys Technology
www.tresys.com

>   In the end it always
> comes down to "how much security are you prepared to endure, given
> that security almost always limits user capability".
> 
> Based on what this article says, it sounds like MACs and ACLs would be
> required because without them they permit you to share data with people
> that may not need that data, people should only have access to the
> limited set of applications and data that they need, and the machine
> should be tightened down to the point where the security approaches
> absolute security.
> 
> While that might fit in with "perfect" security, most people aren't
> interested in that level of perfection.  "Default permit" was so popular
> because it caught the obvious exploits without overly limiting people's
> ability to use a machine.  It is still pretty commonly used today.
> Also, any security protection has a whole range of protections, from
> firewalls, limiting which packages are installed, accounts/passwords,
> validation of users, etc.  Does everyone have to have "perfect" security
> or are there places where a "less than perfect, easy to use, good enough"
> security policy?  I believe there is room for both based on the end
> users' needs and desires.  But that is just my opinion.
> 
> gerrit
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Crispin Cowan]

Karl MacMillan wrote:
> Which is one reason why SELinux has types (equivalence classes) - it
> makes it possible to group large numbers of applications or resources
> into the same security category. The targeted policy that ships with
> RHEL / Fedora shows how this works in practice.
>   
AppArmor (then called "SubDomain") showed how this worked in practice
years before the Targeted Policy came along. The Targeted Policy
implements an approximation to the AppArmor security model, but does it
with domains and types instead of path names, imposing a substantial
cost in ease-of-use on the user.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Arjan van de Ven]

On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
> Karl MacMillan wrote:
> > Which is one reason why SELinux has types (equivalence classes) - it
> > makes it possible to group large numbers of applications or resources
> > into the same security category. The targeted policy that ships with
> > RHEL / Fedora shows how this works in practice.
> >   
> AppArmor (then called "SubDomain") showed how this worked in practice
> years before the Targeted Policy came along. The Targeted Policy
> implements an approximation to the AppArmor security model, but does it
> with domains and types instead of path names, imposing a substantial
> cost in ease-of-use on the user.

I would suspect that the "filename" thing will be the biggest achilles
heel...
after all what does filename mean in a linux world with
* hardlinks
* chroot
* namespaces
* bind mounts
* unlink of open files
* fd passing over unix sockets
* relative pathnames
* multiple threads (where one can unlink+replace file while the other is
in the validation code)

Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Török Edwin]

On Tuesday 18 April 2006 22:50, Arjan van de Ven wrote:
>
> I would suspect that the "filename" thing will be the biggest achilles
> heel...
> after all what does filename mean in a linux world with
> * hardlinks
> * chroot
> * namespaces
> * bind mounts
> * unlink of open files
> * fd passing over unix sockets
> * relative pathnames
> * multiple threads (where one can unlink+replace file while the other is
> in the validation code)

FYI fireflier v1.1.x created rules based on filenames.
In the current version we intended to use mountpoint+inode to identify 
programs. This reduces the potential problems from your list to: fd passing.

Can't AppArmor use inodes in addition to filenames to implement its rules? 
The user could still make its choice based on a "filename" (in an interactive 
userspace program), but by storing additional info along with the filename in 
the rules it would at least uniquely identify the program. 
(P.S.: I don't know how apparmor works, so what i said might not be directly 
applicable).

Note, that since fireflier is going to use SELinux (as soon as I get the 
policy done) program identification isn't shouldn't be a  problem for 
fireflier, but we still have two alternatives:

- use extended attributes to label files, using selinux's setfiles. Most 
secure option IMHO
(BTW can SELinux be told to use another xattr instead of security.selinux? 
Purpose: having multiple policies, and switching between them without the 
need to relabel, i.e. switching between a distro-provided policy/ a custom 
policy/ a fireflier generated policy)

- store rules based on mountpoint+inode+program hash/checksum, and then get 
selinux to label files according to this. Not sure how to do this, and if it 
is worth at all


Cheers,
Edwin

Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Alan Cox]

On Maw, 2006-04-18 at 23:13 +0300, Török Edwin wrote:
> In the current version we intended to use mountpoint+inode to identify 
> programs. This reduces the potential problems from your list to: fd passing.

Inode numbers are not constant on all file systems unless the file is
currently open. That is a pain in the butt when you want to describe a
file as well but it is how things work out.

Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementationof LSM hooks

[David Lang]

On Tue, 18 Apr 2006, Alan Cox wrote:

> Subject: Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementationof
>     LSM hooks
> 
> On Maw, 2006-04-18 at 23:13 +0300, Török Edwin wrote:
>> In the current version we intended to use mountpoint+inode to identify
>> programs. This reduces the potential problems from your list to: fd passing.
>
> Inode numbers are not constant on all file systems unless the file is
> currently open. That is a pain in the butt when you want to describe a
> file as well but it is how things work out.

could you take an approach similar to git, store the length and a hash of 
the first X amount of the file (for good performance say the first block, 
for best security say the entire file)? is there a hash that's cheap 
enough to calculate that this is reasonable? (although it would end up 
trashing the cpu cache in any case, loosing a bunch of the benifits of 
DMA)

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting T?r?k Edwin (edwin@gurde.com):
> On Tuesday 18 April 2006 22:50, Arjan van de Ven wrote:
> >
> > I would suspect that the "filename" thing will be the biggest achilles
> > heel...
> > after all what does filename mean in a linux world with
> > * hardlinks
> > * chroot
> > * namespaces
> > * bind mounts
> > * unlink of open files
> > * fd passing over unix sockets
> > * relative pathnames
> > * multiple threads (where one can unlink+replace file while the other is
> > in the validation code)
> 
> FYI fireflier v1.1.x created rules based on filenames.
> In the current version we intended to use mountpoint+inode to identify 
> programs. This reduces the potential problems from your list to: fd passing.
> 
> Can't AppArmor use inodes in addition to filenames to implement its rules? 
> The user could still make its choice based on a "filename" (in an interactive 

Doesn't help with, for instance, /etc/shadow.  Run passwd once and the
inode number is obsolete.

So either you find a way to decisively use the pathname to identify it,
or you make sure that anyone who can replace it, labels it.

> - use extended attributes to label files, using selinux's setfiles. Most 
> secure option IMHO

Again, xattrs alone may be insufficient if the file can be replaced.

> - store rules based on mountpoint+inode+program hash/checksum, and then get 
> selinux to label files according to this. Not sure how to do this, and if it 
> is worth at all

Again, you're only addressing initial labeling.  But I guess you're
labeling executables so that should be fine.

-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting Arjan van de Ven (arjan@infradead.org):
> On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
> > Karl MacMillan wrote:
> > > Which is one reason why SELinux has types (equivalence classes) - it
> > > makes it possible to group large numbers of applications or resources
> > > into the same security category. The targeted policy that ships with
> > > RHEL / Fedora shows how this works in practice.
> > >   
> > AppArmor (then called "SubDomain") showed how this worked in practice
> > years before the Targeted Policy came along. The Targeted Policy
> > implements an approximation to the AppArmor security model, but does it
> > with domains and types instead of path names, imposing a substantial
> > cost in ease-of-use on the user.
> 
> I would suspect that the "filename" thing will be the biggest achilles
> heel...
> after all what does filename mean in a linux world with
> * hardlinks
> * chroot
> * namespaces
> * bind mounts
> * unlink of open files
> * fd passing over unix sockets
> * relative pathnames
> * multiple threads (where one can unlink+replace file while the other is
> in the validation code)

My old dte module addressed all of these by keeping an in-kernel map
of vfsmounts.  Ok, all the interesting ones - three of them are
solved just by appropriately using file->f_security.

Hardlinks are a pain, but you just have to make up your mind how to
solve them.  In selinux (i believe) the solution is "the first name to
match a rule wins" during labeling, and of course at run-time the labels
are taken from xattrs, and newly created files are based on parent dir
and creating process.  It may be solved in selinux, but since at some
point all initial files must be labeled based on pathname, it still is
an issue to be addressed.

I am curious to see how subdomain will solve these.  And LIDS.  Have
they switched to a install-time xattr labeling + file transition rules
scheme like selinux?  We'll see, it could be interesting.  (Or, it could
be uninteresting and completely wrong...)

-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Crispin Cowan]

Arjan van de Ven wrote:
> On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
>   
>> AppArmor (then called "SubDomain") showed how this worked in practice
>> years before the Targeted Policy came along. The Targeted Policy
>> implements an approximation to the AppArmor security model, but does it
>> with domains and types instead of path names, imposing a substantial
>> cost in ease-of-use on the user.
>>     
> I would suspect that the "filename" thing will be the biggest achilles
> heel...
>   
The filename thing is the core point of AppArmor that distinguishes it
from SELinux. We argue that the work required to make pathname-based
access controls work in the Linux kernel is worth the effort, and we are
putting up the effort to achieve it.

> after all what does filename mean in a linux world with
> * hardlinks
>   
If the policy lets you access /foo/bar/baz then you get to access
/foo/bar/baz, even if it is a hard link to /foo/bif.

Some allege that this is a security hole in AppArmor. However,
AppArmor's design is that you only get to create that hard link if you
are either unconfined or your profile says you get to create it.
AppArmor implicitly trusts all non-confined processes, so anything they
do is ok, by definition. Confined processes can create hard links, but
only if the policy allows them to, and you need access rights greater
than or equal to the access rights of the link source. In order to
create the source, you need to have write access, so in principal you
need write access to the target of your link. So, if you've subverted
the process and you can create the link, you already had write access
*anyway*.

> * chroot
>   
In the currently shipping AppArmor, the names AppArmor sees are
chroot-relative. The patch we are about to submit fixes that and the
names AppArmor sees are now absolute, regardless of chroot jailing.

> * namespaces
> * bind mounts
>   
As far as we know, our namespace support is fine; we mediate attempts to
modify namespaces (such as denying mount and umount) and requiring
cap_sys_chroot to modify the root of the namespace. If there are
instances where we are incorrect we would greatly appreciate a detailed
description of the issue (or better a testcase) so we can look at
resolving it.

> * unlink of open files
> * fd passing over unix sockets
>   
AppArmor initially validates your access at open time, and there after
you can read&write to it without mediation. AppArmor re-validates your
access if policy is reloaded, you exec() a new program, you get passed
the fd from another process, or you call our change_hat() API.

So, if the file is unlinked or renamed while you have it open, and
policy says you don't have access to the new name, then:

    * within the same process you get to keep accessing it until
          o policy is reloaded by the administrator
          o you call the change_hat() API
    * in some other process, either a child or some process you passed
      an fd to, you don't get to access it because your access gets
      revalidated

Note that d_path still returns pathnames for files that have been
removed from the filesystem (that are open)
> * relative pathnames
>   
If you access "../hosts.allow" AppArmor will canonicalize your path name
to /etc/hosts.allow before checking the policy.

> * multiple threads (where one can unlink+replace file while the other is
> in the validation code)
>   
I'm not sure what your getting at here. For fine grained concurrency, we
believe that AppArmor gets its kernel locks right; if you see a problem,
please point it out. For coarser grained concurrency, your threads can
mangle each other to the extent that your policy allows them to.
Generally speaking, highly concurrent threads are likely to be living in
very similar or identical policies anyway.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Arjan van de Ven]

On Wed, 2006-04-19 at 11:32 -0700, Crispin Cowan wrote:
> Arjan van de Ven wrote:
> > On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
> >   
> >> AppArmor (then called "SubDomain") showed how this worked in practice
> >> years before the Targeted Policy came along. The Targeted Policy
> >> implements an approximation to the AppArmor security model, but does it
> >> with domains and types instead of path names, imposing a substantial
> >> cost in ease-of-use on the user.
> >>     
> > I would suspect that the "filename" thing will be the biggest achilles
> > heel...
> >   
> The filename thing is the core point of AppArmor that distinguishes it
> from SELinux. We argue that the work required to make pathname-based
> access controls work in the Linux kernel is worth the effort, and we are
> putting up the effort to achieve it.

if you mean "to make it user manageable" I don't buy your argument. If
you would have made the policy using path names, but a policy compiler
that turns it into file object attributes + a compiled policy using
attributes you achieve the same ease of use. However you get the
security on the object rather than on the pointers to the object.
 
> 
> > after all what does filename mean in a linux world with
> > * hardlinks
> >   
> If the policy lets you access /foo/bar/baz then you get to access
> /foo/bar/baz, even if it is a hard link to /foo/bif.
> 
> Some allege that this is a security hole in AppArmor. However,
> AppArmor's design is that you only get to create that hard link if you
> are either unconfined or your profile says you get to create it.
> AppArmor implicitly trusts all non-confined processes, so anything they
> do is ok, by definition. Confined processes can create hard links, but
> only if the policy allows them to, and you need access rights greater
> than or equal to the access rights of the link source. In order to
> create the source, you need to have write access, so in principal you
> need write access to the target of your link. So, if you've subverted
> the process and you can create the link, you already had write access
> *anyway*.

and this falls appart if you can compromise 2 daemons with
non-overlapping permissions. or in many other situations ;)

> 
> > * chroot
> >   
> In the currently shipping AppArmor, the names AppArmor sees are
> chroot-relative. The patch we are about to submit fixes that and the
> names AppArmor sees are now absolute, regardless of chroot jailing.

what is an absolute path? How does that work if you have namespaces or
floating mounts? (eg after lazy umount for example)

> 
> > * namespaces
> > * bind mounts
> >   
> As far as we know, our namespace support is fine; we mediate attempts to
> modify namespaces (such as denying mount and umount)

but you can trick other parts in the system to mount/umount stuff anyway
(hal for example)
and still clone is the part that plays with namespaces most

>  and requiring
> cap_sys_chroot to modify the root of the namespace. If there are
> instances where we are incorrect we would greatly appreciate a detailed
> description of the issue (or better a testcase) so we can look at
> resolving it.

you don't get to control it. Simple example: hal doing a lazy umount on
your usb stick.


> > * unlink of open files
> > * fd passing over unix sockets

> >    you get passed
> the fd from another process, or you call our change_hat() API.

how do you validate the fd? the there no longer is a filename for that
file (it may be unlinked, renamed, lazy umounted etc etc)

> Note that d_path still returns pathnames for files that have been
> removed from the filesystem (that are open)

it does return "something". It just doesn't return meaningful pathnames.
At all.


> > * relative pathnames
> >   
> If you access "../hosts.allow" AppArmor will canonicalize your path name
> to /etc/hosts.allow before checking the policy.

and does it do that for recursive symlinks? And what if I'm dynamically
playing with the symlink tree while you're resolving?

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Jan Engelhardt]

>
>> Note that d_path still returns pathnames for files that have been
>> removed from the filesystem (that are open)
>
>it does return "something". It just doesn't return meaningful pathnames.
>At all.
>
Exactly. It currently appends " (deleted)", which may even match an
existing file!

E.g.:
$ touch blah "blah (deleted)"
$ perl -e 'open I,blah;unlink blah;sleep 60' &
$ ls -l /proc/`echo $! `/fd/
lr-x------  1 jengelh root 64 Apr 19 21:48 3 -> /dev/shm/blah (deleted)

Note that ls will not colorize the part after ->, since that file actually
exists!


Jan Engelhardt
-- 

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

On Wed, 19 Apr 2006 11:32:56 PDT, Crispin Cowan said:

> AppArmor initially validates your access at open time, and there after
> you can read&write to it without mediation. AppArmor re-validates your
> access if policy is reloaded, you exec() a new program, you get passed
> the fd from another process, or you call our change_hat() API.
> 
> So, if the file is unlinked or renamed while you have it open, and
> policy says you don't have access to the new name, then:
> 
>     * within the same process you get to keep accessing it until
>           o policy is reloaded by the administrator
>           o you call the change_hat() API
>     * in some other process, either a child or some process you passed
>       an fd to, you don't get to access it because your access gets
>       revalidated

My brain is small, and my eyes glaze over easily... ;)

What happens for the following sequence:

a) Process A does   fd = open("/some/protected");
b) Somebody then does an unlink("/some/protected");
c) A then does a fork/exec, handing the exec'ed process B the open FD 
as its stdin.

What name do you use to re-validate B's access to the data described by
the inode that open file is referencing?

Note that although B can't get any access to the data that A didn't have,
it can still be used to bypass security, because B may be able to *copy* that
data to an area where A couldn't write (presumably because A is in a confined box).

This can be mitigated by saying "A can't fork/exec" - which may not work if
A in fact needs to exec things (webserver CGI comes to mind).  I don't see
any provision for saying "A can only exec B, C, and D and nothing else..."

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Tony Jones]

On Wed, Apr 19, 2006 at 02:50:40PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 19 Apr 2006 11:32:56 PDT, Crispin Cowan said:
> 
> > AppArmor initially validates your access at open time, and there after
> > you can read&write to it without mediation. AppArmor re-validates your
> > access if policy is reloaded, you exec() a new program, you get passed
> > the fd from another process, or you call our change_hat() API.
> > 
> > So, if the file is unlinked or renamed while you have it open, and
> > policy says you don't have access to the new name, then:
> > 
> >     * within the same process you get to keep accessing it until
> >           o policy is reloaded by the administrator
> >           o you call the change_hat() API
> >     * in some other process, either a child or some process you passed
> >       an fd to, you don't get to access it because your access gets
> >       revalidated
> 
> My brain is small, and my eyes glaze over easily... ;)

Join the club :)

> What happens for the following sequence:
> 
> a) Process A does   fd = open("/some/protected");
> b) Somebody then does an unlink("/some/protected");
> c) A then does a fork/exec, handing the exec'ed process B the open FD 
> as its stdin.

I just wrote the following which I believe is your test scenario?

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main()
{
int fd, err, pid;

	fd = open("/tmp/protected", O_RDONLY);
	if (fd == -1){
		perror("open") ; return 1;
	}

	err=unlink("/tmp/protected");
	if (err == -1){
		perror("unlink"); close(fd); return 1;
	}

	pid=fork();

	if (pid){
		wait();
	}else{
		close(0);
		dup(fd);

		execl("/bin/cat", "/bin/cat", NULL);
	}

	close(fd);
}

d_path reports "/tmp/protected (deleted)" for the dentry in this situation 
when /bin/cat attempts to access it.

It happens a lot with nscd which likes to open files, unlink them and pass
them over unix domain sockets.  Our old code used to have to remove the 
(deleted) [in a safe manner of course]. With the posted patch to d_path to
generate pathnames back to the namespace root I took advantage of including
some control of the appending for unhashed dentries.

> What name do you use to re-validate B's access to the data described by
> the inode that open file is referencing?

Now how you handle what confinement the forked process should have is 
determined when you generate policy. /bin/cat in this situation can run under
it's own policy (probably not ideal in this situation), inherit the openers
(probably the ideal choice), or none at all (if you believe it does not
require confinement).

> Note that although B can't get any access to the data that A didn't have,
> it can still be used to bypass security, because B may be able to *copy* that
> data to an area where A couldn't write (presumably because A is in a confined box).

I'm not sure how.  Perhaps with the above example you can elaborate as 
necessary.  Also thanks for posting the question.

Tony

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
> Karl MacMillan wrote:
> > Which is one reason why SELinux has types (equivalence classes) - it
> > makes it possible to group large numbers of applications or resources
> > into the same security category. The targeted policy that ships with
> > RHEL / Fedora shows how this works in practice.
> >   
> AppArmor (then called "SubDomain") showed how this worked in practice
> years before the Targeted Policy came along. The Targeted Policy
> implements an approximation to the AppArmor security model, but does it
> with domains and types instead of path names, imposing a substantial
> cost in ease-of-use on the user.

Just to clarify a few points:
- It is true that both AppArmor and SELinux with targeted policy only
(effectively) restrict a subset of processes, but SELinux with targeted
policy provides complete mediation of all objects and operations for
those processes, not just capabilities and files like AppArmor.
   
- Targeted policy demonstrates that a general purpose mechanism that is
capable of complete mediation of all processes, objects, and operations
(SELinux) can be applied to selective control if that is your goal.  The
reverse is not true; AppArmor is limited by its design.

- Ease of use should be addressed in the user interface, not by using a
broken kernel mechanism.   There is ongoing work to address the
useability of SELinux in userspace; it doesn't require changing the
kernel mechanism to rely on pathnames (which is broken).

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Crispin Cowan]

Stephen Smalley wrote:
> On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
>   
>> AppArmor (then called "SubDomain") showed how this worked in practice
>> years before the Targeted Policy came along. The Targeted Policy
>> implements an approximation to the AppArmor security model, but does it
>> with domains and types instead of path names, imposing a substantial
>> cost in ease-of-use on the user.
>>     
> Just to clarify a few points:
> - It is true that both AppArmor and SELinux with targeted policy only
> (effectively) restrict a subset of processes, but SELinux with targeted
> policy provides complete mediation of all objects and operations for
> those processes, not just capabilities and files like AppArmor.
>   
Agreed, with the caveat that mediating all those things comes with
expense, and AppArmor doesn't mediate them by design, because our goal
is to keep the host from being compromised by a hacked application, not
to control all information flow. Different goals produce different designs.

> - Targeted policy demonstrates that a general purpose mechanism that is
> capable of complete mediation of all processes, objects, and operations
> (SELinux) can be applied to selective control if that is your goal.  The
> reverse is not true; AppArmor is limited by its design.
>   
Also agreed, and also caveated that the general purpose system emulating
the simple system is much more complex than the simple system itself,
and simplicity is a critical part of secure design. In this case, the
most expensive impact on simplicity is the complexity of the policy that
users have to manage.

> - Ease of use should be addressed in the user interface, not by using a
> broken kernel mechanism.   There is ongoing work to address the
> useability of SELinux in userspace; it doesn't require changing the
> kernel mechanism to rely on pathnames (which is broken).
>   
Mediating by file names rather than inodes is the fundamental place
where we disagree. I am delighted with LSM, because it allows us to
disagree without having to fight about it.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Greg KH]

On Tue, Apr 18, 2006 at 01:35:48PM -0700, Crispin Cowan wrote:
> > - Ease of use should be addressed in the user interface, not by using a
> > broken kernel mechanism.   There is ongoing work to address the
> > useability of SELinux in userspace; it doesn't require changing the
> > kernel mechanism to rely on pathnames (which is broken).
> >   
> Mediating by file names rather than inodes is the fundamental place
> where we disagree.

The main problem with "mediating by file names" in Linux these days is
(as I'm sure you know) the whole fun of binds, namespaces and other
lovely things that people do with filesystems (see the fun that
ClearCase does with bind mounts on the latest 2.6 kernel for an example
of the nightmare that "file names" will cause.)

Yes, users are used to filenames, but fortunatly they don't matter to
the kernel.

> I am delighted with LSM, because it allows us to disagree without
> having to fight about it.

LSM doesn't care about filenames, but inodes.  So you both are not
disagreeing :)

thanks,

greg k-h

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Tue, 2006-04-18 at 13:35 -0700, Crispin Cowan wrote:
> Agreed, with the caveat that mediating all those things comes with
> expense, and AppArmor doesn't mediate them by design, because our goal
> is to keep the host from being compromised by a hacked application, not
> to control all information flow. Different goals produce different designs.

It isn't just a matter of information flow control, although that is
foundational to higher level confidentiality _and_ integrity guarantees.
Perhaps a more specific example would be helpful.  Attacker compromises
network-exposed client or server program on your system that you are
"confining" via AppArmor.  Assume that the attacker knows that your
system is protected by AppArmor, and has studied the AppArmor
implementation and default configurations (no security through
obscurity).  Knowing that AppArmor does nothing to control inter-process
operations or IPC beyond capability checks (which are only applied when
the base DAC checks fail or for "privileged" ops), he proceeds to
subvert another local process via such an inter-process mechanism,
completely unrestricted by AppArmor.  As that other local process wasn't
"confined" by AppArmor (or protected by it against such subversion),
attacker now has unrestricted access to the machine.  Now go back to
your thunderbird profile that you posted elsewhere and think hard about
the real implications of your having given it cap_setuid, without even
knowing why. 

> Also agreed, and also caveated that the general purpose system emulating
> the simple system is much more complex than the simple system itself,
> and simplicity is a critical part of secure design. In this case, the
> most expensive impact on simplicity is the complexity of the policy that
> users have to manage.

Assurance in the base mechanism is crucial, and it isn't possible when
the base mechanism is relying on incomplete and inaccurate information.
Ala pathnames.  Policy does get complex, but that is just because what
is happening on the system is complex, and SELinux policy is analyzable,
with open source tools available to perform extensive analysis of it.
At the end of the day, you can say that a SELinux policy does or does
not achieve a higher level security goal.  You can never do that with
the AppArmor mechanism; you just never know.

> Mediating by file names rather than inodes is the fundamental place
> where we disagree. I am delighted with LSM, because it allows us to
> disagree without having to fight about it.

Here I fear you will be disappointed, as I have looked at the LSM hook
interfaces, and I have looked at AppArmor's implementation, and it is
clear that LSM is the wrong implementation approach for AppArmor, even
assuming that AppArmor's technical approach is sound.  LSM just doesn't
fit with your needs, because the hooks are at the wrong places and take
the wrong inputs for pathname-based control.  You don't get the
(vfsmount, dentry) pairs you need from the LSM inode hooks.  What I find
particularly puzzling about this is that your team was involved in LSM
development, and could have sought at the time to get that information,
either by putting the hooks at different locations or by seeking to
propagate the information down to the callers (although there are issues
there).  But they didn't.  Instead, AppArmor goes through great
contortions to get pathnames (often having to iterate through all
possibilities) for its purposes.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Alan Cox]

On Maw, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
> implements an approximation to the AppArmor security model, but does it
> with domains and types instead of path names, imposing a substantial
> cost in ease-of-use on the user.

I don't think thats true. A file name is a pretty meaningless object in
Unixspace let alone Linux after Al Plan9ified it somewhat. It has an
impact on policy design but if anything it makes it slightly harder for
the policy design work and _easier_ for users, who no longer have to
follow magic path rules.

If you think about it, what matters is the object not the name. Who
cares what a 'cool executable' file from the internet is called. If I'm
doing policy for a large corporate then I wan't it not to be executable
unless someone has blessed it. It can be in /tmp in a users home
directory or in /var/spool/mail. Either way I don't care what it is
called just what it *is*.

Can you answer the "when are you submitting it upstream" question ? I've
certainly not got any fundamental objection to another security system.
I doubt we'd all use it but we don't all use sys5 file systems or
reiserfs either.

Alan

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Crispin Cowan]

Alan Cox wrote:
> On Maw, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
>   
>> implements an approximation to the AppArmor security model, but does it
>> with domains and types instead of path names, imposing a substantial
>> cost in ease-of-use on the user.
>>     
> I don't think thats true. A file name is a pretty meaningless object in
> Unixspace let alone Linux after Al Plan9ified it somewhat.
Not quite; data contents and file names have *different* meanings.
Mediating the contents of the shadow file is good for preserving the
secrecy of the file. Mediating the contents of the thing named
/etc/hosts.allow has impact with respect to what answers to that name,
regardless of what happened to the previous contents.

SELinux has NSA legacy, and that is reflected in their inode design: it
is much better at protecting secrecy, which is the NSA's historic
mission. AppArmor has legacy in intrusion prevention, and so its primary
design goal was to prevent compromised programs from compromising the
host. Name-based access control is better at that, because it lets you
directly control which programs can change the contents of path names
that have critical semantic meaning in UNIX/Linux, such as /etc/shadow,
/etc/hosts.allow, /srv/www/htdocs/index.html and so forth.

>  It has an
> impact on policy design but if anything it makes it slightly harder for
> the policy design work and _easier_ for users, who no longer have to
> follow magic path rules.
>   
Try out AppArmor and see if you still believe that :)

> Can you answer the "when are you submitting it upstream" question ?
It is a small number of hours away. We are polishing our submission now.

>  I've
> certainly not got any fundamental objection to another security system.
> I doubt we'd all use it but we don't all use sys5 file systems or
> reiserfs either.
>   
I very much appreciate that. AppArmor is fundamentally different than
SELinux, in goals and in the resulting design, and we believe it is
important for users to be able to choose the system they want, both in
file systems and security systems.

Note: I'm assuming that LSM will not be removed while we are in the
process of being reviewed. I seem to recall it took SELinux six months
to go from initial submission to acceptance and I'm sure we will have to
fix issues and we don't have illusions that AppArmor will be accepted in
a matter of weeks.

We had actually planned to submit AppArmor next week, and this thread
has accelerated the submission by a few days.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[James Morris]

On Tue, 18 Apr 2006, Crispin Cowan wrote:

> SELinux has NSA legacy, and that is reflected in their inode design: it
> is much better at protecting secrecy, which is the NSA's historic
> mission.

No.  The inode design is simply correct.

Consider the following:

What if Unix DAC security was implemented via pathnames, using a 
configuration file and regexp matching enginer in the kernel, invoked 
during file access, rather than the existing scheme of checking inode 
ownership and permission attributes?

SELinux labels objects directly because it's the right thing to do.

To also clarify: the legacy of SELinux is in the decades of research 
performed into providing more comprehensive security than the original 
secrecy-oriented TCSEC schemes.  And conflating a highly loaded term such 
as "NSA's historic mission" with an implementation specific aspect of 
SELinux is useless in a technical discussion and IMHO totally 
inappropriate.



- James
-- 
James Morris
<jmorris@namei.org>

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Crispin Cowan]

James Morris wrote:
> On Tue, 18 Apr 2006, Crispin Cowan wrote:
>   
>> SELinux has NSA legacy, and that is reflected in their inode design: it
>> is much better at protecting secrecy, which is the NSA's historic
>> mission.
>>     
> No.  The inode design is simply correct.
>   
"Correct" for what? inode access control is correct if data secrecy is
your number one objective. It is not necessarily correct for other purposes.

> Consider the following:
>
> What if Unix DAC security was implemented via pathnames, using a 
> configuration file and regexp matching enginer in the kernel, invoked 
> during file access, rather than the existing scheme of checking inode 
> ownership and permission attributes?
>   
What of it? That sounds very close to the AppArmor design, except for
the "discretionary" part. Just what is wrong with it? If your main
complaint is that you would miss having chmod and umask, then I agree:
we are not proposing to remove classic DAC. So what's your point?

> SELinux labels objects directly because it's the right thing to do.
>   
Security design by Wilford Brimley: emphatic assertion :)

AppArmor is a fully functional access control system that works on
pathname-based access controls. I'm sorry if it violates your religion
for it to exist and work. Claiming that pathname-based access control is
"broken" or "wrong" is about as useful as standing at Kitty Hawk in 1903
exclaiming that heavier-than-air flight is impossible. You don't have to
like it, but denying its existence is nonsense.

> To also clarify: the legacy of SELinux is in the decades of research 
> performed into providing more comprehensive security than the original 
> secrecy-oriented TCSEC schemes.  And conflating a highly loaded term such 
> as "NSA's historic mission" with an implementation specific aspect of 
> SELinux is useless in a technical discussion and IMHO totally 
> inappropriate.
>   
It is totally appropriate because it goes to the core reason for the
design difference between AppArmor and SELinux. The NSA, and indeed all
intelligence agencies, have secrecy as their #1 security need. inode
labels is absolutely the right way to achieve that.

However, I assert (emphatically :) that the broader user community has
integrity and availability as higher priorities than secrecy, and that
pathname-based access control is a better way to achieve that. I want to
offer Linux users the choice of pathname-based access control if they
want it. Why do you want to prevent them from having that choice?

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Chris Wright]

* Crispin Cowan (crispin@novell.com) wrote:
> However, I assert (emphatically :) that the broader user community has
> integrity and availability as higher priorities than secrecy, and that
> pathname-based access control is a better way to achieve that. I want to
> offer Linux users the choice of pathname-based access control if they
> want it. Why do you want to prevent them from having that choice?

I'm in favor of choice.  And it's no doubt that users appreciate the
intuitiveness of pathname based security.  The real question is the
actual security of the system.  What we don't want is a choice that
embodies any false sense of security.  So that is why it's important to
understand how AppArmor protects from the pathname based attacks.

thanks,
-chris

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[James Morris]

On Tue, 18 Apr 2006, Crispin Cowan wrote:

> >> SELinux has NSA legacy, and that is reflected in their inode design: it
> >> is much better at protecting secrecy, which is the NSA's historic
> >> mission.
> >>     
> > No.  The inode design is simply correct.
> >   
> "Correct" for what? inode access control is correct if data secrecy is
> your number one objective. It is not necessarily correct for other purposes.

It's correct for deterministically and safely applying security policy 
when accessing a file.

With pathnames, there is an unbounded and unknown number of effective 
security policies on the system, as there are an unbounded and unknown 
number of ways of viewing the files via pathnames.

> > What if Unix DAC security was implemented via pathnames, using a 
> > configuration file and regexp matching enginer in the kernel, invoked 
> > during file access, rather than the existing scheme of checking inode 
> > ownership and permission attributes?
> >   
> What of it? That sounds very close to the AppArmor design, except for
> the "discretionary" part. Just what is wrong with it? If your main
> complaint is that you would miss having chmod and umask, then I agree:
> we are not proposing to remove classic DAC. So what's your point?

The point is to illustrate the basic AppArmor mechanism, using a security 
model which people already know and understand.


> > SELinux labels objects directly because it's the right thing to do.
> >   
> Security design by Wilford Brimley: emphatic assertion :)

As Arjan already pointed out, pathname security doesn't work for:

* hardlinks
* chroot
* namespaces
* bind mounts
* unlink of open files
* fd passing over unix sockets
* relative pathnames
* multiple threads (where one can unlink+replace file while the other is
  in the validation code)


Direct object labeling is the only mechanism which allows you to perform 
reliable access control checks against those objects.


> However, I assert (emphatically :) that the broader user community has
> integrity and availability as higher priorities than secrecy, and that
> pathname-based access control is a better way to achieve that.

Integrity control is a fundamental aspect of SELinux, implemented via Type 
Enforcement.  Please refer to:

  W. Boebert and R. Yain. "A Practical Alternative to Hierarchical 
  Integrity Policies." In Proceedings National Computer Security 
  Conference, 1985.


> I want to offer Linux users the choice of pathname-based access control 
> if they want it. Why do you want to prevent them from having that 
> choice?

My opinion is that it's fundamentally broken as the core mechanism of an 
access control mechanism, although there are places where it can make 
sense.

All I'm doing at this stage is responding to your comments on SELinux, as 
unfortunately, from prior experience, if they go unchallenged, many people 
will believe them to be correct.



- James
-- 
James Morris
<jmorris@namei.org>

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Casey Schaufler]

--- James Morris <jmorris@namei.org> wrote:


> With pathnames, there is an unbounded and unknown
> number of effective 
> security policies on the system, as there are an
> unbounded and unknown 
> number of ways of viewing the files via pathnames.

I agree that for traditional DAC and MAC (including
the flavors supported by SELinux) inodes is the
only way to go. SELinux is a traditional Trusted OS
architecture and addresses the traditional Trusted
OS issues. 

But as someone demonstrated earlier, not everyone
believes that an EAL makes them feel secure and that
is what LSM is really all about, allowing people
who don't care about Protection Profiles but who do
care about security to do something about it. How
many of you have lambasted me over the years because
I bled Orange? If SELinux is the only "secure" Linux
haven't the Orange Book/Common Criteria people proven
right in the end?




Casey Schaufler
casey@schaufler-ca.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Kyle Moffett]

On Apr 18, 2006, at 21:48:56, Casey Schaufler wrote:
> --- James Morris <jmorris@namei.org> wrote:
>> With pathnames, there is an unbounded and unknown number of  
>> effective security policies on the system, as there are an
>> unbounded and unknown number of ways of viewing the files via  
>> pathnames.
>
> I agree that for traditional DAC and MAC (including the flavors  
> supported by SELinux) inodes is the only way to go. SELinux is a  
> traditional Trusted OS architecture and addresses the traditional  
> Trusted OS issues.

Perhaps the SELinux model should be extended to handle (dir-inode,  
path-entry) pairs.  For example, if I want to protect the /etc/shadow  
file regardless of what tool is used to safely modify it, I would set  
up security as follows:

o  Protect the "/" and "/etc" directory inodes as usual under SELinux  
(with attributes on directory inodes).
o  Create pairs with (etc_inode,"shadow") and (etc_inode,"gshadow")  
and apply security attributes to those potentially nonexistent pairs.

I'm not terribly familiar with the exact internal semantics of  
SELinux, but that should provide a 90% solution (it fixes bind mounts  
and namespaces).  The remaining 2 issues are hardlinks and fd- 
passing.  For hardlinks you don't care about other links to that  
data, you're concerned with protecting a particular filesystem  
location, not particular contents, so you just need to prevent _new_  
hardlinks to a protected (dir_inode, path_elem) pair, which doesn't  
seem very hard.  For fd-passing, I don't know what to do.  Perhaps  
nothing.

Anyways, just a few ideas for consideration

Cheers,
Kyle Moffett

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:
> Perhaps the SELinux model should be extended to handle (dir-inode,
> path-entry) pairs.  For example, if I want to protect the /etc/shadow
> file regardless of what tool is used to safely modify it, I would set

Some of us think that the tools can protect /etc/shadow just fine on their
own, and are concerned with rogue software that abuses /etc/shadow without
bothering to safely modify it..

> up security as follows:
> 
> o  Protect the "/" and "/etc" directory inodes as usual under SELinux  
> (with attributes on directory inodes).
> o  Create pairs with (etc_inode,"shadow") and (etc_inode,"gshadow")  
> and apply security attributes to those potentially nonexistent pairs.

*bzzt* wrong.  Why should "gshadow" matter? (Think carefully about what
happens when a setUID program gets exploited and used to scribble on /etc/shadow -
black hats rarely bother to do locking and other such niceties....)

> I'm not terribly familiar with the exact internal semantics of
> SELinux, but that should provide a 90% solution (it fixes bind mounts

90% doesn't give the security guys warm-and-fuzzies....

> and namespaces).  The remaining 2 issues are hardlinks and fd-
> passing.  For hardlinks you don't care about other links to that
> data, you're concerned with protecting a particular filesystem
> location, not particular contents, so you just need to prevent _new_
> hardlinks to a protected (dir_inode, path_elem) pair, which doesn't 
> seem very hard.

It's not. include/linux/security.h:

 * @inode_link:
 *      Check permission before creating a new hard link to a file.
 *      @old_dentry contains the dentry structure for an existing link to the file.
 *      @dir contains the inode structure of the parent directory of the new link.
 *      @new_dentry contains the dentry structure for the new link.
 *      Return 0 if permission is granted.

>                 For fd-passing, I don't know what to do.  Perhaps  
> nothing.

include/linux/security.h:

 * @file_receive:
 *      This hook allows security modules to control the ability of a process
 *      to receive an open file descriptor via socket IPC.
 *      @file contains the file structure being received.
 *      Return 0 if permission is granted.

Already a solved problem.



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu):
> On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:
> > Perhaps the SELinux model should be extended to handle (dir-inode,
> > path-entry) pairs.  For example, if I want to protect the /etc/shadow
> > file regardless of what tool is used to safely modify it, I would set
> 
> Some of us think that the tools can protect /etc/shadow just fine on their
> own, and are concerned with rogue software that abuses /etc/shadow without
> bothering to safely modify it..

Can you rephrase this?  I'm don't understand what you're saying...

My default response would have to be:

> own, and are concerned with rogue software that abuses /etc/shadow without
> bothering to safely modify it..

rogue software like vi?

thanks,
-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

On Wed, 19 Apr 2006 06:41:06 CDT, "Serge E. Hallyn" said:
> Quoting Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu):
> > On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:
> > > Perhaps the SELinux model should be extended to handle (dir-inode,
> > > path-entry) pairs.  For example, if I want to protect the /etc/shadow
> > > file regardless of what tool is used to safely modify it, I would set
> > 
> > Some of us think that the tools can protect /etc/shadow just fine on their
> > own, and are concerned with rogue software that abuses /etc/shadow without
> > bothering to safely modify it..
> 
> Can you rephrase this?  I'm don't understand what you're saying...
> 
> My default response would have to be:
> 
> > own, and are concerned with rogue software that abuses /etc/shadow without
> > bothering to safely modify it..
> 
> rogue software like vi?

Close enough.  I was actually thinking of a script kiddie with a canned tool
that does 'echo foo::0:0: >> /etc/passwd' type stuff, but vi without its vipw
component would count too....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Gene Heskett]

On Wednesday 19 April 2006 07:41, Serge E. Hallyn wrote:
>Quoting Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu):
>> On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:
>> > Perhaps the SELinux model should be extended to handle (dir-inode,
>> > path-entry) pairs.  For example, if I want to protect the
>> > /etc/shadow file regardless of what tool is used to safely modify
>> > it, I would set
>>
>> Some of us think that the tools can protect /etc/shadow just fine on
>> their own, and are concerned with rogue software that abuses
>> /etc/shadow without bothering to safely modify it..
>
>Can you rephrase this?  I'm don't understand what you're saying...
>
>My default response would have to be:
>> own, and are concerned with rogue software that abuses /etc/shadow
>> without bothering to safely modify it..
>
>rogue software like vi?

Don't you go pickin on vi now, ya hear?

>thanks,
>-serge
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Kyle Moffett]

On Apr 19, 2006, at 02:56:28, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:
>> Perhaps the SELinux model should be extended to handle (dir-inode,  
>> path-entry) pairs.  For example, if I want to protect the /etc/ 
>> shadow file regardless of what tool is used to safely modify it, I  
>> would set
>
> Some of us think that the tools can protect /etc/shadow just fine  
> on their own, and are concerned with rogue software that abuses / 
> etc/shadow without bothering to safely modify it..

Here I'm talking about using SELinux to protect /etc/shadow both  
before _and_ after it's edited with vipw.  A tool like vipw does creat 
() write() rename() to overwrite the /etc/shadow file, so any SELinux  
system relying _only_ on inode is guaranteed to break.  In any case,  
the point here is to provide 2 clean semantics for protecting files:  
inodes and directory entries;  They have entirely different use- 
cases.  For an inode all you need is (<inode>), for a directory entry  
you need (<dir-inode>, <path-component>).  The latter would only be  
used when referencing the file by name, if you already have a  
filehandle it would not be used.

>> o  Protect the "/" and "/etc" directory inodes as usual under SELinux
>> (with attributes on directory inodes).
>> o  Create pairs with (etc_inode,"shadow") and (etc_inode,"gshadow")
>> and apply security attributes to those potentially nonexistent pairs.
>
> *bzzt* wrong.  Why should "gshadow" matter? (Think carefully about  
> what happens when a setUID program gets exploited and used to  
> scribble on /etc/shadow - black hats rarely bother to do locking  
> and other such niceties....)

/etc/gshadow matters because it's the group shadow file, no?  If  
you're going to bother protecting the user shadow file, you should  
protect the group shadow file too.

>> I'm not terribly familiar with the exact internal semantics of  
>> SELinux, but that should provide a 90% solution (it fixes bind  
>> mounts and namespaces).
>
> 90% doesn't give the security guys warm-and-fuzzies....

True, but that's why I address the following 2 items below:

>> The remaining 2 issues are hardlinks and fd-passing.  For  
>> hardlinks you don't care about other links to that data, you're  
>> concerned with protecting a particular filesystem location, not  
>> particular contents, so you just need to prevent _new_ hardlinks  
>> to a protected (dir_inode, path_elem) pair, which doesn't seem  
>> very hard.
>
> It's not. include/linux/security.h:
>
>  * @inode_link:
>  *      Check permission before creating a new hard link to a file.
>  *      @old_dentry contains the dentry structure for an existing  
> link to the file.
>  *      @dir contains the inode structure of the parent directory  
> of the new link.
>  *      @new_dentry contains the dentry structure for the new link.
>  *      Return 0 if permission is granted.

I _think_ SELinux provides a way to hook this, but I'm not entirely  
sure.  If not, it should be added, but I suspect it does.

>> For fd-passing, I don't know what to do.  Perhaps nothing.
>
> include/linux/security.h:
>
>  * @file_receive:
>  *      This hook allows security modules to control the ability of  
> a process
>  *      to receive an open file descriptor via socket IPC.
>  *      @file contains the file structure being received.
>  *      Return 0 if permission is granted.
>
> Already a solved problem.

Likewise, this should be solved with inode-based security if it's a  
problem.  The use-case I'm addressing (legitimate use of /etc/shadow  
with vipw) doesn't care about that.  For example, if I want to only  
allow vipw access to /etc/shadow, then associating that policy with  
the /etc/shadow inode is useless, because the first rogue program  
would just remove and rewrite /etc/shadow, getting a different  
inode.  What I need to do is protect the "shadow" entry in the dentry  
for ("/etc") in the particular namespace I care about, right?

Cheers,
Kyle Moffett

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Thu, 2006-04-20 at 02:51 -0400, Kyle Moffett wrote:
> On Apr 19, 2006, at 02:56:28, Valdis.Kletnieks@vt.edu wrote:
> > On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:
> >> Perhaps the SELinux model should be extended to handle (dir-inode,  
> >> path-entry) pairs.  For example, if I want to protect the /etc/ 
> >> shadow file regardless of what tool is used to safely modify it, I  
> >> would set
> >
> > Some of us think that the tools can protect /etc/shadow just fine  
> > on their own, and are concerned with rogue software that abuses / 
> > etc/shadow without bothering to safely modify it..
> 
> Here I'm talking about using SELinux to protect /etc/shadow both  
> before _and_ after it's edited with vipw.  A tool like vipw does creat 
> () write() rename() to overwrite the /etc/shadow file, so any SELinux  
> system relying _only_ on inode is guaranteed to break.

To clarify:
- SELinux kernel access controls are configured by policy to ensure that
only approved tools can manipulate the file (based on inode attribute,
initially established at install time),
- SELinux kernel labeling mechanism for new inodes is configured by
policy to ensure that new files created by such tools are labeled with
the most restrictive label (i.e. the one for shadow, not passwd data) by
default, so that we don't leak information accidentally,
- Approved tools/libraries are instrumented to specify the desired label
for passwd vs. shadow (and backup files), since the same code re-creates
both on a transaction (at least when adding/removing users), so the
kernel can't make that distinction automatically; only the tool knows
that.  This is consistent with how DAC mode is handled for passwd vs.
shadow. 

No pathname-based mechanism in the kernel required, or desired.  Names
are meaningless to real security properties.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Nix]

On 20 Apr 2006, Stephen Smalley yowled:
> - Approved tools/libraries are instrumented to specify the desired label
> for passwd vs. shadow (and backup files), since the same code re-creates
> both on a transaction (at least when adding/removing users), so the
> kernel can't make that distinction automatically; only the tool knows
> that.  This is consistent with how DAC mode is handled for passwd vs.
> shadow. 

So... every program which may modify labelled entities (e.g., for files,
by unlink()/creat()) needs modification for SELinux?

This strikes me as rather impractical if you want to be able to label
files that users may edit: there are a lot of programs users run that
`modify' files in that way. For starters, every web browser, every text
editor...  is it really sensible to require modification of *almost
everything* that can overwrite files lest you magically lose labels that
you thought you had?

(With AppArmor, of course, you never lose labels at all, because there
aren't any.)

(I may be missing something, but I know that when I've tried to use
SELinux to constrain what such programs could manipulate, I was
losing labels to unlink()/creat() left right and centre.)

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Fri, 2006-04-21 at 02:00 +0100, Nix wrote:
> On 20 Apr 2006, Stephen Smalley yowled:
> > - Approved tools/libraries are instrumented to specify the desired label
> > for passwd vs. shadow (and backup files), since the same code re-creates
> > both on a transaction (at least when adding/removing users), so the
> > kernel can't make that distinction automatically; only the tool knows
> > that.  This is consistent with how DAC mode is handled for passwd vs.
> > shadow. 
> 
> So... every program which may modify labelled entities (e.g., for files,
> by unlink()/creat()) needs modification for SELinux?

No.  In the common case, you just configure policy to ensure that files
created by the program are labeled properly.  That works as long as the
same process doesn't end up creating two separate files in the same
directory that need to be protected in different ways (as with programs
that re-create both passwd and shadow for e.g. adding and removing
users).  At that point, you are dealing with application level knowledge
of the difference between those two files, and that application has to
maintain the difference (it already has to maintain separation of the
actual data, so it is the right place to do the labeling at that point).
This is the same for file modes or ACLs as well as SELinux attributes.
You can still use SELinux policy in that case to ensure that the default
label is the most restrictive one, so that you don't accidentally leak
or permit modification of the information, but the application has to
deal with the finer granularity of identifying which file has which
security label.  Other option is to split the program into helpers, with
each helper specialized to updating one of those files, and then just
configure policy to label them differently automatically.

> This strikes me as rather impractical if you want to be able to label
> files that users may edit: there are a lot of programs users run that
> `modify' files in that way. For starters, every web browser, every text
> editor...  is it really sensible to require modification of *almost
> everything* that can overwrite files lest you magically lose labels that
> you thought you had?

A few points:
- The label is supposed to reflect the security properties of the
object.  So it is typically based on the creating process' label and a
related object (parent directory label).  Consequently, if files live in
different subdirectories or if they are edited by different processes
(e.g. user logs in or newrole's to different roles/domains/levels), then
they would get different labels anyway, without the editor needing to be
aware.
- In the case where the same process is allowed to edit multiple files
that live in the same parent directory and the files are supposed to
have different labels (i.e. different protection requirements), then
yes, the editor has to preserve the label.  No different than file
modes, ACLS, whatever.  That is then an application-level distinction;
the application knows what data is being written where, and thus what it
should be labeled.  Not the job of the kernel.
- The label preservation problem will gradually diminish over time as
more programs become aware and as policy becomes more complete in its
coverage.  Much of the current pain is due to a combination of
incomplete policy coverage (in particular, targeted policy doesn't deal
with users and user apps at present, vs. strict policy) and incomplete
integration with applications.  Same issue will apply to any new
security model, whether ACLs or MAC.

> (With AppArmor, of course, you never lose labels at all, because there
> aren't any.)

But you do lose preservation of security properties, e.g. renaming a
file suddenly moves it under different protection.  Same end result.
Their labels just happen to be pathnames, which also suffer from being
ambiguous.

> (I may be missing something, but I know that when I've tried to use
> SELinux to constrain what such programs could manipulate, I was
> losing labels to unlink()/creat() left right and centre.)

As above, this reflects incomplete policy coverage and application
integration, and that will diminish over time.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Lars Marowsky-Bree]

On 2006-04-21T10:24:37, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> > (With AppArmor, of course, you never lose labels at all, because there
> > aren't any.)
> But you do lose preservation of security properties, e.g. renaming a
> file suddenly moves it under different protection.  Same end result.

This is not correct, as far as I understand. As the app can only rename
in it has access to both the old and the new path.


-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Mon, 24 Apr 2006 10:14:34 +0200, Lars Marowsky-Bree said:
> On 2006-04-21T10:24:37, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > > (With AppArmor, of course, you never lose labels at all, because there
> > > aren't any.)
> > But you do lose preservation of security properties, e.g. renaming a
> > file suddenly moves it under different protection.  Same end result.
> 
> This is not correct, as far as I understand. As the app can only rename
> in it has access to both the old and the new path.

People seem to have a blind spot for this sort of thing.  Given *two* processes,
one of which can be convinced to do a rename, and another that can be convinced
to write a file, you can subvert everything (quite possibly in opposite order -
if you can get process A to write /etc/foobar, and process B to rename foobar
to passwd, you've won).

Those who think that 2 processes can't be subverted should consider that symlink
attacks have been around for a quarter of a century - and in that time, it's
*always* been "one process to create the symlink, another to follow it to disaster".


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Nix]

On Mon, 24 Apr 2006, Valdis Kletnieks stated:
>> This is not correct, as far as I understand. As the app can only rename
>> in it has access to both the old and the new path.
> 
> People seem to have a blind spot for this sort of thing.  Given *two* processes,
> one of which can be convinced to do a rename, and another that can be convinced
> to write a file, you can subvert everything (quite possibly in opposite order -
> if you can get process A to write /etc/foobar, and process B to rename foobar
> to passwd, you've won).

If those processes are exposed enough that external attackers can talk
to them at all, they should be confined. And anyone who allows confined
processes to write to /etc or create or rename links in /etc at all is
an idiot.

Are we *really* defending against people who write blatantly idiotic
profiles? (What's more, unlike with SELinux, it's guaranteed to be easy
to see that that profile is idiotic, because the policy language is so
simple.)

(Obviously creating or renaming links in /** is every bit as
bad. Don't-write-stupid-profiles rule again.)

(I'm assuming a post-chroot()-absolute-paths world: in the previous
world, as exemplified by the current example profiles, /** is sane *if
and only if* the confined app is always chrooted.)

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Arjan van de Ven]

On Wed, 2006-04-19 at 02:40 -0400, Kyle Moffett wrote:
> On Apr 18, 2006, at 21:48:56, Casey Schaufler wrote:
> > --- James Morris <jmorris@namei.org> wrote:
> >> With pathnames, there is an unbounded and unknown number of  
> >> effective security policies on the system, as there are an
> >> unbounded and unknown number of ways of viewing the files via  
> >> pathnames.
> >
> > I agree that for traditional DAC and MAC (including the flavors  
> > supported by SELinux) inodes is the only way to go. SELinux is a  
> > traditional Trusted OS architecture and addresses the traditional  
> > Trusted OS issues.
> 
> Perhaps the SELinux model should be extended to handle (dir-inode,  
> path-entry) pairs.  For example, if I want to protect the /etc/shadow  
> file regardless of what tool is used to safely modify it, I would set  
> up security as follows:
> 
> o  Protect the "/" and "/etc" directory inodes as usual under SELinux  
> (with attributes on directory inodes).

in which namespace are these? And are they in a chroot?
And what if someone makes /etd a symlink to /etc :)
And what if I bind-mount something on top of /etc/shadow ?
or unlink the file while holding it open? Should the security suddenly
go away? There's no "directory" for this file anymore at that point.
Or if I hardlink /etc/shadhow to /tmp/shad ... what then?


> o  Create pairs with (etc_inode,"shadow") and (etc_inode,"gshadow")  
> and apply security attributes to those potentially nonexistent pairs

again see above ;_)

> .
> 
> I'm not terribly familiar with the exact internal semantics of  
> SELinux, but that should provide a 90% solution (it fixes bind mounts  
> and namespaces).

how does this fix namespaces or even bind mounts?
(or even symlinks for that matter)

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting Kyle Moffett (mrmacman_g4@mac.com):
> On Apr 18, 2006, at 21:48:56, Casey Schaufler wrote:
> >--- James Morris <jmorris@namei.org> wrote:
> >>With pathnames, there is an unbounded and unknown number of  
> >>effective security policies on the system, as there are an
> >>unbounded and unknown number of ways of viewing the files via  
> >>pathnames.
> >
> >I agree that for traditional DAC and MAC (including the flavors  
> >supported by SELinux) inodes is the only way to go. SELinux is a  
> >traditional Trusted OS architecture and addresses the traditional  
> >Trusted OS issues.
> 
> Perhaps the SELinux model should be extended to handle (dir-inode,  
> path-entry) pairs.  For example, if I want to protect the /etc/shadow  
> file regardless of what tool is used to safely modify it, I would set  
> up security as follows:

Perhaps linux should keep it's momentum toward p9-ish and implement a
factotum service.

Note what we're trying to do:
	1. make the mount tree as dynamic as possible, per-process.
	So my /var/spool can be completely different from yours,
	on the same machine.
	2. but to let process p5 authenticate as root, privileged code
	trusts info stored in hardcoded pathnames in p5's current mount
	tree.
In other words, we want to prevent just a few pathnames from being
replaced through a bind mount/pivot_root/whatever.

Would make much more sense to have one thread running in an initial
private fs namespace, using pathnames it knows it can trust to dole
out privs.

I recall at last year's OLS Eric Van Hensbergen led a talk to discuss
problems involved in allowing unprivileged user mounts, where this
idea came up.  But of course no one (that I know of) has been crazy
enough to try it.

-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Wed, 2006-04-19 at 02:40 -0400, Kyle Moffett wrote:
> On Apr 18, 2006, at 21:48:56, Casey Schaufler wrote:
> > --- James Morris <jmorris@namei.org> wrote:
> >> With pathnames, there is an unbounded and unknown number of  
> >> effective security policies on the system, as there are an
> >> unbounded and unknown number of ways of viewing the files via  
> >> pathnames.
> >
> > I agree that for traditional DAC and MAC (including the flavors  
> > supported by SELinux) inodes is the only way to go. SELinux is a  
> > traditional Trusted OS architecture and addresses the traditional  
> > Trusted OS issues.
> 
> Perhaps the SELinux model should be extended to handle (dir-inode,  
> path-entry) pairs.  For example, if I want to protect the /etc/shadow  
> file regardless of what tool is used to safely modify it, I would set  
> up security as follows:

SELinux already provides a way to protect /etc/shadow, in a much
stronger way.  It does require some library/application modifications
(already present in some distros) to preserve a different security label
on files containing shadow data than on files containing public passwd
data, but that is no different than the existing approach for preserving
different file modes on those files.  It doesn't require the kernel to
deal with pathnames itself.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Tue, 2006-04-18 at 18:48 -0700, Casey Schaufler wrote:
> 
> --- James Morris <jmorris@namei.org> wrote:
> 
> 
> > With pathnames, there is an unbounded and unknown
> > number of effective 
> > security policies on the system, as there are an
> > unbounded and unknown 
> > number of ways of viewing the files via pathnames.
> 
> I agree that for traditional DAC and MAC (including
> the flavors supported by SELinux) inodes is the
> only way to go. SELinux is a traditional Trusted OS
> architecture and addresses the traditional Trusted
> OS issues. 

Hmmm..can't say that SELinux has been accused of being a "traditional
trusted OS architecture" before.  Flask and TE aren't precisely
traditional.  But it does preserve the key characteristics required to
support real MAC.

> But as someone demonstrated earlier, not everyone
> believes that an EAL makes them feel secure and that
> is what LSM is really all about, allowing people
> who don't care about Protection Profiles but who do
> care about security to do something about it. How
> many of you have lambasted me over the years because
> I bled Orange? If SELinux is the only "secure" Linux
> haven't the Orange Book/Common Criteria people proven
> right in the end?

This would be fine, if the technical approach were sound (not
necessarily the same as SELinux, but sound) and fit properly with the
LSM interface.  But the path-based approach isn't technically sound, and
even if we were to assume that it was, it isn't even a good fit for the
LSM hook interfaces.
 
-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> This would be fine, if the technical approach were
> sound (not necessarily the same as SELinux, but
sound)

Please accept that this is a judgement call.

> and fit properly with the LSM interface.

Of course LSM will fit SELinux better than it fits
AppArmour, LSM has been adapted to fit the needs
of SELinux. Once AppArmour, LIDS, and friends have
been accepted LSM will adjust to serve them better
just as it has done for SELinux. If the arguement
is that a module can't be accepted because it
doesn't do the same things SELinux does, and that
there's no point in accepting it if it does the
same things SELinux does I will admit that you have
all the bases covered.

> But the path-based approach isn't technically sound,

That is certainly true for a Common Criteria
system. There are clued individuals who understand
all the underlying technology who still care
about *any* file called /etc/shadow, chroot, mount,
vfs, and phase of the moon notwithstanding.

> and even if we were to assume that it was, it isn't
even
> a good fit for the LSM hook interfaces.

SELinux wasn't always a good fit either. LSM
accomodated SELinux. Offer the same community
cooperation to other you have yourself received.


Casey Schaufler
casey@schaufler-ca.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Wed, 2006-04-19 at 09:42 -0700, Casey Schaufler wrote:
> 
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > This would be fine, if the technical approach were
> > sound (not necessarily the same as SELinux, but
> sound)
> 
> Please accept that this is a judgement call.

Judgment calls have to be made all the time; this is no different.  One
would hope that particularly in the arena of security, sound judgment
would be applied.  In this particular case, it isn't just security folks
who are troubled by reliance on pathnames, and there are plenty of prior
discussions on linux-fsdevel and linux-kernel describing the brokenness
of path-based approaches.  Why would the answer be different now?

> > and fit properly with the LSM interface.
> 
> Of course LSM will fit SELinux better than it fits
> AppArmour, LSM has been adapted to fit the needs
> of SELinux. 

This is a gross misrepresentation of the facts and history of LSM.  LSM
was jointly developed, and the initial VFS inode hooks were proposed by
none other than the WireX folks, i.e. the developers of
SubDomain/AppArmor.  From that initial proposal, though the entire
development of LSM, through the 2.5 development series after LSM was
merged, and through the 2.6 stable series so far, no one from the
AppArmor side has ever suggested a need to change the hooks to better
accomodate their needs.  Yet if you look at their implementation (and I
have, have you?), you'll see that they have to go through contortions
because the LSM interface is such a mismatch for what they do.  That
isn't due to any "adaptations" for SELinux.

> SELinux wasn't always a good fit either. LSM
> accomodated SELinux. Offer the same community
> cooperation to other you have yourself received.

Community cooperation doesn't mean embracing unsound ideas.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:
 
> One would hope that particularly in the arena of
> security, sound judgment
> would be applied.  In this particular case, it isn't
> just security folks
> who are troubled by reliance on pathnames, and there
> are plenty of prior
> discussions on linux-fsdevel and linux-kernel
> describing the brokenness
> of path-based approaches.  Why would the answer be
> different now?

Just to be clear here, not everyone is comfortable
with the idea of a security "policy" that is
developed,
maintained, and stored independently of the kernel
and the applications to which it is applied.
The SELinux approach took a good deal of selling
within the community before it gained traction,
and a good many of the voices I've heard today
spoke out against SELinux in the beginning. It is
still far from universally regarded as the ultimate
solution.

> > Of course LSM will fit SELinux better than it fits
> > AppArmour, LSM has been adapted to fit the needs
> > of SELinux. 
> 
> This is a gross misrepresentation of the facts and
> history of LSM.

Perhaps. The SELinux community has made significant
contributions to the LSM effort might be a more
politic way to say it, but in the end the changes
made by the SELinux community were done for the
benefit of SELinux. This is only natural and to be
expected.

> LSM was jointly developed, and the initial VFS inode
> hooks were proposed by
> none other than the WireX folks, i.e. the developers
> of SubDomain/AppArmor.

Yes, I remember it well. The Bumper Patch of Fun
and the resulting Bruhaha over authoritative hooks
will feature prominently in my tell-all book.

> From that initial proposal, though the entire
> development of LSM, through the 2.5 development
> series after LSM was
> merged, and through the 2.6 stable series so far, no
> one from the
> AppArmor side has ever suggested a need to change
> the hooks to better accomodate their needs.

Now that's just not true. Crispin was very active in
the very early days. He didn't always get what he
wanted, but he certainly asked for it many times.

> Yet if you look at their implementation (and I
> have, have you?), you'll see that they have to go
> through contortions
> because the LSM interface is such a mismatch for
> what they do.  That
> isn't due to any "adaptations" for SELinux.

I am sure that LSM, being a community effort, can
evolve over time for AppArmour just as it has for
SELinux and any other user that invests (that's a
key) in the effort. SELinux has provided the lion's
share of value to LSM over the past couple years.
It is both appropriate and to be expected that LSM
has lost much of its independence from SELinux
under such circumstances.

> > SELinux wasn't always a good fit either. LSM
> > accomodated SELinux. Offer the same community
> > cooperation to other you have yourself received.
> 
> Community cooperation doesn't mean embracing unsound
> ideas.

It is well known that I am far from convinced
that the policy file basis of SELinux is sound.
Many people of demonstrated intelligence think
it is. Personally, I suspect that both Stephen
and Crispin are smarter than I am, and I believe
that both have value to add to the community with
the approaches they've developed. The same goes
for LIDS, LOMAX, other projects I've seen but
may not name.

Let's not chicken out. Linux is too young to get
stodgy.


Casey Schaufler
casey@schaufler-ca.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[James Morris]

[dropped fireflier-devel]

On Wed, 19 Apr 2006, Casey Schaufler wrote:

> Just to be clear here, not everyone is comfortable with the idea of a 
> security "policy" that is developed, maintained, and stored 
> independently of the kernel and the applications to which it is applied.

This has never been required; it's just the way standard policy was 
developed historically.

The current trend is to move policy development to the packages being 
protected, made possible through the recent modular policy work by Tresys.  
Several developer tools are being developed to help support this.

(SELinux developments of note are posted at: http://selinuxnews.org/wp/ 
and in the various blogs linked there).



- James
-- 
James Morris
<jmorris@namei.org>

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Chris Wright]

* James Morris (jmorris@namei.org) wrote:
> The current trend is to move policy development to the packages being 
> protected, made possible through the recent modular policy work by Tresys.  
> Several developer tools are being developed to help support this.

I agree, this is the sanest model.  Ideally it could be expressed in
some form directly from app developers...I can dream ;-)

thanks,
-chris

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Casey Schaufler]

--- James Morris <jmorris@namei.org> wrote:


> No.  The inode design is simply correct.

If this were true audit records would not be required
to contain path names. Names are important. To meet
EAL requirements path names are demonstrably
insufficient, but so too are inode numbers. Unless
you want to argue that Linux is unevaluateable
(a pretty tough position to defend) because it
requires both in an audit record you cannot claim
either is definitive.


Casey Schaufler
casey@schaufler-ca.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Christoph Hellwig]

On Tue, Apr 18, 2006 at 04:16:57PM -0700, Casey Schaufler wrote:
> 
> 
> --- James Morris <jmorris@namei.org> wrote:
> 
> 
> > No.  The inode design is simply correct.
> 
> If this were true audit records would not be required
> to contain path names. Names are important. To meet
> EAL requirements path names are demonstrably
> insufficient, but so too are inode numbers. Unless
> you want to argue that Linux is unevaluateable
> (a pretty tough position to defend) because it
> requires both in an audit record you cannot claim
> either is definitive.

Sure you can log the pathname to comply with useless
standards.  It doesn't make it any more meaningfull,
though.

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Arjan van de Ven]

On Tue, 2006-04-18 at 16:16 -0700, Casey Schaufler wrote:
> 
> --- James Morris <jmorris@namei.org> wrote:
> 
> 
> > No.  The inode design is simply correct.
> 
> If this were true audit records would not be required
> to contain path names. Names are important. To meet
> EAL requirements path names are demonstrably
> insufficient, but so too are inode numbers. Unless
> you want to argue that Linux is unevaluateable
> (a pretty tough position to defend) because it
> requires both in an audit record you cannot claim
> either is definitive.

audit != SELinux, simple as that
And yes audit on filenames is not too useful, but it is in some cases:
Consider the case where you want to log that someone tried to unlink
a file that doesn't exist. Inodes aren't going to do you any good ;)

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Tue, 2006-04-18 at 13:57 -0700, Crispin Cowan wrote:
> SELinux has NSA legacy, and that is reflected in their inode design: it
> is much better at protecting secrecy, which is the NSA's historic
> mission. AppArmor has legacy in intrusion prevention, and so its primary
> design goal was to prevent compromised programs from compromising the
> host. Name-based access control is better at that, because it lets you
> directly control which programs can change the contents of path names
> that have critical semantic meaning in UNIX/Linux, such as /etc/shadow,
> /etc/hosts.allow, /srv/www/htdocs/index.html and so forth.

This is bunk, pure and simple.  The core security model of SELinux is
Type Enforcement, and Type Enforcement was originally used for
integrity, as a mechanism for complementing and filling in the gaps left
by the MLS (secrecy/confidentiality) model.  Type Enforcement can be
used for confidentiality as well, as it is just a simplification of the
Lampson access matrix, but its original goals were integrity oriented.
Name-based access control is _not_ better for integrity.  You don't want
trusted program FOO (e.g. /bin/su) to accept data from an untrustworthy
file that happens to be named /etc/shadow in your namespace, so you want
your integrity controls to be governed by the real security attributes
of the real object, not just its name.  The only argument I've seen
regarding "names are better for integrity" is that it is easier to
preserve the association when the object is re-created at that location.
But that association may be fallacious - if an untrustworthy process
re-created /etc/shadow, I don't want it to retain an association with
high integrity data.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Casey Schaufler]

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> ... A file name is a pretty
> meaningless object in Unixspace ...

Stephen is right that the inode is the object.
Crispin is right that people care about path names.

The linux-audit folks have been hashing this
about good and hard. It is true that both the
pathname /etc/shadow and the inode it represents
are interesting from various secuirty viewpoints.
If you insist on either being the definitive
security referent you will be wrong about half
the time.


Casey Schaufler
casey@schaufler-ca.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Arjan van de Ven]

On Tue, 2006-04-18 at 16:09 -0700, Casey Schaufler wrote:
> --- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > ... A file name is a pretty
> > meaningless object in Unixspace ...
> 
> Stephen is right that the inode is the object.
> Crispin is right that people care about path names.
> 
> The linux-audit folks have been hashing this
> about good and hard. It is true that both the
> pathname /etc/shadow and the inode it represents
> are interesting from various secuirty viewpoints.
> If you insist on either being the definitive
> security referent you will be wrong about half
> the time.

just that LSM is inode based ;)

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Alan Cox]

On Maw, 2006-04-18 at 09:50 -0700, Gerrit Huizenga wrote:
> > [1] http://www.ranum.com/security/computer_security/editorials/dumb/
> 
> Interesting but I'm not impressed by the article.  I think Stephen's

Its really a quick summary of ideas, and you need to read other stuff
beyond it to treat it as more than a "wakey wakey" piece. I'd also
suggest reading Ross Andersons work on the economics of computer
security if you haven't already.

> machine, these two approaches start to converge.  In the end it always
> comes down to "how much security are you prepared to endure, given
> that security almost always limits user capability".

You need to define "you" in the above to start with. Thats very
important in the sense that SELinux is capable of protecting systems
from their users to an extent (users are remarkably resourceful little
critters). The big goal in the Fedora case is that users don't notice
the security. 

> or are there places where a "less than perfect, easy to use, good enough"
> security policy?  I believe there is room for both based on the end
> users' needs and desires.  But that is just my opinion.

Poor security systems lead to less security than no security because it
lulls people into a false sense of security. Someone who knows their
house is insecure doesn't keep valuable items in it. Someone who thinks
their house is secure but it is not increases the risk not decreases it.

Doing good security is hard, and it does need to be from a "default
deny" basis. Ask anyone at IBM who remembers the default PATH starting
"." in AIX. Removing that was a move from default allow to default deny.
Nobody today would consider it anything but sane. Ditto the default
firewall on most Linux distros is 'default deny', something I did from
day one with Lokkit.

A security system that merely looks good is as useful as a database that
looks pretty but doesn't always store the data you asked it to, and
probably more dangerous.

Alan

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> On Maw, 2006-04-18 at 09:50 -0700, Gerrit Huizenga wrote:
> > or are there places where a "less than perfect, easy to use, good enough"
> > security policy?  I believe there is room for both based on the end
> > users' needs and desires.  But that is just my opinion.
> 
> Poor security systems lead to less security than no security because it
> lulls people into a false sense of security. Someone who knows their

Not wanting to make any digs one way or another, but because the culture
right now refuses to admit it I must point out:

So does "security" which is too complicated and therefore ends up
misconfigured (or disabled).

The posix caps sendmail fiasco is one example.

-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Tue, 2006-04-18 at 14:59 -0500, Serge E. Hallyn wrote:
> Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > On Maw, 2006-04-18 at 09:50 -0700, Gerrit Huizenga wrote:
> > > or are there places where a "less than perfect, easy to use, good enough"
> > > security policy?  I believe there is room for both based on the end
> > > users' needs and desires.  But that is just my opinion.
> > 
> > Poor security systems lead to less security than no security because it
> > lulls people into a false sense of security. Someone who knows their
> 
> Not wanting to make any digs one way or another, but because the culture
> right now refuses to admit it I must point out:
> 
> So does "security" which is too complicated and therefore ends up
> misconfigured (or disabled).

Not sure who refuses to admit it, but there is plenty of work in
progress to improve SELinux useability.  But that doesn't require
crippling the kernel mechanism, nor would that help.  Keep in mind as
well that SELinux "complexity" is purely a reflection of complexity in
Linux; SELinux just exposes the existing interactions and provides a way
to control them.  The SELinux mechanism itself is fairly simple.  

> The posix caps sendmail fiasco is one example.


-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Tue, 2006-04-18 at 14:59 -0500, Serge E. Hallyn wrote:
> > Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > > On Maw, 2006-04-18 at 09:50 -0700, Gerrit Huizenga wrote:
> > > > or are there places where a "less than perfect, easy to use, good enough"
> > > > security policy?  I believe there is room for both based on the end
> > > > users' needs and desires.  But that is just my opinion.
> > > 
> > > Poor security systems lead to less security than no security because it
> > > lulls people into a false sense of security. Someone who knows their
> > 
> > Not wanting to make any digs one way or another, but because the culture
> > right now refuses to admit it I must point out:
> > 
> > So does "security" which is too complicated and therefore ends up
> > misconfigured (or disabled).
> 
> Not sure who refuses to admit it, but there is plenty of work in
> progress to improve SELinux useability.  But that doesn't require

Yes, absolutely, some very good work.

I used to think I'd want selinux protecting the TCB, but worried about
user customizations threatening the integrity of the TCB policy.  But
the namespace extension (.) may even allay that fear.

-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Casey Schaufler]

--- "Serge E. Hallyn" <serue@us.ibm.com> wrote:


> The posix caps sendmail fiasco is one example.

Sendmail with POSIX Capabilities works great
on Irix, which is the system it was developed
for. Irix, unlike Linux, supports (but, in
keeping with IEEE rules does not claim to
conform to) the POSIX Capabilities exec(2)
symantics. The sendmail work was done in
anticipation of Linux supporting Posix
Capabilities. Alas, the xattr work on Linux
was not done before the Company The Built Irix
ran out of money to spend on security* and
the push to get capabilities working right
never materialized. Sorry.

----
* I'm not bitter. Oh no, it goes way beyond bitter.


Casey Schaufler
casey@schaufler-ca.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Bernhard R. Link]

* Alan Cox <alan@lxorguk.ukuu.org.uk> [060418 21:20]:
> Poor security systems lead to less security than no security because it
> lulls people into a false sense of security. Someone who knows their
> house is insecure doesn't keep valuable items in it. Someone who thinks
> their house is secure but it is not increases the risk not decreases it.
> 
> Doing good security is hard, and it does need to be from a "default
> deny" basis.

Too strict security can also lead to less security than no security at
all. This is especialy true if security of only a part is too strict.

If system config files are only readable by root (or some admin role),
people will work as root (or with that admin role) to read them,
instead of adding some new config-file-reading group/role.
If users are forbidden to log in remotely via ssh, they might run
outgoing ssh portforwarding some telnet-like protocol in. If you
restrict what can be run on the computers too much, people might try
to plug in their laptops. If you force the doors locked and give too
few people a key, they will start leaving the windows open.

Hochachtungsvoll,
	Bernhard R. Link

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

Hi,

On Tue, Apr 18, 2006 at 12:58:19PM +0100, Christoph Hellwig wrote:
> It's doing access control on pathnames, which can't work in unix enviroments.
> It's following the default permit behaviour which causes pain in anything
> security-related (compare [1]).

Pathnames are problematic, no doubt.
So AppArmor does currently do some less-than-nice things to get around
this.
On the other side, pathnames is what the admins see and use, so it is
the right abstraction for the sysadmin, if you want to make a higher
level of security available to people without the need to get them
a large amount of extra training.
So that gap needs to be bridged somehow.
Maybe there are better ways compared to what AA does currently, and
constructive suggestions are very welcome!

And no, just claiming that AA is useless or crap is not constructive
AFAICT. And saying that is should be better done as part of SElinux
is not either.

The goals are quite different. SElinux is a solution that wants to
implement policies that cover lots of things. It's accordingly powerful
and complex.

AppArmor is easy. Everyone with a little background in Un*x can
understand what it does and how it needs to be configured.
Eventually, most sysadmins of the world can configure it correctly
and thus make their systems more secure.
(The submission to LKML should happen RSN, the committment has
 been there since a long time!)

I don't want to judge, but I think the approaches and goals are 
different enough to grant both (and evetually others) the right 
to live.

Actually, I'm a bit worried about the discussion.
When I chose Linux, it was about the freedom of choice.
And we have a nice abstraction (LSM) that allows this freedom. At
a small price. It's not pleasant to see that some people want to move
away from that.

Best,
-- 
Kurt Garloff, Head Architect Linux R&D, Novell Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

On Tue, 18 Apr 2006 23:38:33 +0200, Kurt Garloff said:
> AppArmor is easy. Everyone with a little background in Un*x can
> understand what it does and how it needs to be configured.
> Eventually, most sysadmins of the world can configure it correctly
> and thus make their systems more secure.

Having spent a quarter century in which cleaning up after other sysadmins
has played a major role, I think you're vastly overstating the average clue level
out there.

Most of the readers of this list can (hopefully) snarf a linux-2.foo.tar.bz2
and end up with a bootable kernel on their own.  The *actual* average sysadmin
out there has trouble getting something like 'up2date' (or the Ubuntu equivalent)
to update an already vendor-compiled kernel.

Experience has shown that if you make the sysadmin configure it using anything
more than 1 or 2 very broad knobs ("fairly secure, very secure, tinfoil-hat secure"),
it *very* quickly becomes a way for them to create security holes in their system,
and doesn't add any actual security.

And the instant you abstract it all behind a point-and-drool GUI with a choice
of 3 buttons to click, it doesn't matter anymore, because the distro vendor
will be doing all the heavy lifting.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Arjan van de Ven]

> Actually, I'm a bit worried about the discussion.
> When I chose Linux, it was about the freedom of choice.
> And we have a nice abstraction (LSM) that allows this freedom. 

While I agree with the "freedom" part, I would not call the LSM
abstraction "nice". It's not. Part of the reason for that is that there
weren't more "real" users, only "ghost" ones, so fixing the interface to
fit the users hasn't been done. "removing" LSM seems to be an attempt to
fit the interface to all real users at the time. Once there's > 1, the
fix can be different ;)

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Serge E. Hallyn]

Quoting Kurt Garloff (garloff@suse.de):
> Hi,
> 
> On Tue, Apr 18, 2006 at 12:58:19PM +0100, Christoph Hellwig wrote:
> > It's doing access control on pathnames, which can't work in unix enviroments.
> > It's following the default permit behaviour which causes pain in anything
> > security-related (compare [1]).
> 
> Pathnames are problematic, no doubt.
> So AppArmor does currently do some less-than-nice things to get around
> this.
> On the other side, pathnames is what the admins see and use, so it is
> the right abstraction for the sysadmin, if you want to make a higher
> level of security available to people without the need to get them
> a large amount of extra training.
> So that gap needs to be bridged somehow.
> Maybe there are better ways compared to what AA does currently, and
> constructive suggestions are very welcome!
> 
> And no, just claiming that AA is useless or crap is not constructive
> AFAICT. And saying that is should be better done as part of SElinux
> is not either.

Ok, but...  why not?

Have you ever tried, at 4pm some afternoon, sitting in a room with some
paper and implementing the AA user interface on top of selinux?

An initial selinux policy can basically be:

print "type base_t;"

for c in object_class:
	"allow base_t base_t:c *;"

Then, if the AA user has a profile

	/bin/login {
		/etc/shadow r
	}

it creates domain login_t, entry type login_et assigned to /bin/login,
and shadow_t as a type which login_t can only read, but non-restricted
domains (i.e. base_t) can read and write.  It also makes read and write
macros for a bunch of selinux perms (i.e. ioctl, etc), the way the
Tresys CDE tool does.

I do want LSM to survive, and am reserving my judgement of AA until
I see the code, but if it really is just about ease of use, then
perhaps it should be a pure userspace thing?

OTOH perhaps there are reasons why you can't do this, and you can
explain why the above won't work.

-serge

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Yuichi Nakamura]

Hi,it is my first post to the LSM list.

"Serge E. Hallyn" wrote:
> Have you ever tried, at 4pm some afternoon, sitting in a room with 
> somepaper and implementing the AA user interface on top of selinux?
We've implemented AppArmor like configuration on top of SELinux.
SELinux Policy Editor(http://seedit.sourceforge.net/) does this.
In its current development version(not released yet, only in CVS), 
Configuration for httpd is like below.

#####
{
domain httpd_t;
program /usr/sbin/httpd;
include common-relaxed.sp;
include daemon.sp;
include nameservice.sp;
allow /etc s;
allow /etc/httpd/** r,s;
allow /var/log/httpd/** r,a,s;
allow /var/www/** r,s;
allow /var s;
allow /var/run/** s;
allow /etc/php.d/** r,s;
allow /etc/php.ini r,s;
allow /etc/mime.types r,s;
allow /etc/pki/** r,s;
allownet -protocol tcp -port 80,443 server;
}
#####
Above is converted into SELinux Policy language.
Types, allow rules,domain transision rules are generated.
It works, and can also restrict IPC and privilege other than POSIX
capability(because it is based on SELinux).

However, path-name based configuration can not be achieved on SELinux in
following cases.
1) Files on file system that does not support xattr(such as sysfs)
   SELinux policy editor handles all files as same on such file systems.
2) Files that are dynamically created/deleted(inode number is not fixed).
   Example is files on /tmp and /etc/mtab. SELinux Policy Editor is
using file type transition to configure access control for them.


--
---
Yuichi Nakamura
Japan SELinux Users Group(JSELUG)
SELinux Policy Editor:  http://seedit.sourceforge.net/

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Greg KH]

On Wed, Apr 19, 2006 at 08:55:56AM -0400, Yuichi Nakamura wrote:
> However, path-name based configuration can not be achieved on SELinux in
> following cases.
> 1) Files on file system that does not support xattr(such as sysfs)
>    SELinux policy editor handles all files as same on such file systems.

Hm, I've thought about this in the past and wonder if we should add
xattr support to sysfs.  Would it be useful for things like SELinux?
The files would not be created with any xattrs, but would be able to
have them once they are set.  Would that be good enough?

thanks,

greg k-h

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Wed, 2006-04-19 at 08:44 -0700, Greg KH wrote:
> On Wed, Apr 19, 2006 at 08:55:56AM -0400, Yuichi Nakamura wrote:
> > However, path-name based configuration can not be achieved on SELinux in
> > following cases.
> > 1) Files on file system that does not support xattr(such as sysfs)
> >    SELinux policy editor handles all files as same on such file systems.
> 
> Hm, I've thought about this in the past and wonder if we should add
> xattr support to sysfs.  Would it be useful for things like SELinux?
> The files would not be created with any xattrs, but would be able to
> have them once they are set.  Would that be good enough?

The generic security xattr fallback behavior in the VFS already provides
us with most of what we need there.  The only thing missing is a way to
preserve the attributes when inodes are evicted and later re-created
from sysfs_dirent.  One of our people was experimenting with a patch to
save and restore that information, but we are waiting for some of the
audit work to finalize as that exports some interfaces from SELinux to
the rest of the kernel that we need.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Greg KH]

On Wed, Apr 19, 2006 at 12:02:32PM -0400, Stephen Smalley wrote:
> On Wed, 2006-04-19 at 08:44 -0700, Greg KH wrote:
> > On Wed, Apr 19, 2006 at 08:55:56AM -0400, Yuichi Nakamura wrote:
> > > However, path-name based configuration can not be achieved on SELinux in
> > > following cases.
> > > 1) Files on file system that does not support xattr(such as sysfs)
> > >    SELinux policy editor handles all files as same on such file systems.
> > 
> > Hm, I've thought about this in the past and wonder if we should add
> > xattr support to sysfs.  Would it be useful for things like SELinux?
> > The files would not be created with any xattrs, but would be able to
> > have them once they are set.  Would that be good enough?
> 
> The generic security xattr fallback behavior in the VFS already provides
> us with most of what we need there.  The only thing missing is a way to
> preserve the attributes when inodes are evicted and later re-created
> from sysfs_dirent.

Yeah, without that, it's probably pretty useless :)
Take a look at the patch that added support for owner/mode settings, it
shouldn't be that hard to also add xattr support there.

> One of our people was experimenting with a patch to save and restore
> that information, but we are waiting for some of the audit work to
> finalize as that exports some interfaces from SELinux to the rest of
> the kernel that we need.

That sounds fine, thanks for letting me know.

greg k-h

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Crispin Cowan]

Yuichi Nakamura wrote:
> "Serge E. Hallyn" wrote:
>   
>> Have you ever tried, at 4pm some afternoon, sitting in a room with 
>> somepaper and implementing the AA user interface on top of selinux?
>>     
> We've implemented AppArmor like configuration on top of SELinux.
> SELinux Policy Editor(http://seedit.sourceforge.net/) does this.
>   
This is a fascinating piece of work. A compiler to compile
(approximately) AppArmor policies into SELinux policies.

> Above is converted into SELinux Policy language.
> Types, allow rules,domain transision rules are generated.
>   
Does it label the file system as well? If not, then the path names you
can specify with different access rights would be very limited. If so,
then any change to the policy requires a relabellings.

> It works, and can also restrict IPC and privilege other than POSIX
> capability(because it is based on SELinux).
>   
We have plans to enhance AppArmor to mediate IPC and network access.
Some of these plans are constrained by the limits of LSM, and once
AppArmor is in-tree, we hope to propose some LSM enhancements to make
that work better.

> However, path-name based configuration can not be achieved on SELinux in
> following cases.
> 1) Files on file system that does not support xattr(such as sysfs)
>    SELinux policy editor handles all files as same on such file systems.
>   
More than just sysfs. All network attached storage (NFS mounted file
systems) cannot support xattr. One could imagine supporting xattr for
Linux-based NFS servers, but that just won't work for non-linux storage
servers.

As a consequence, SELinux policies can only grant all-or-nothing access
to the entire NFS-mounted file system. This is a big deal for larger
data centers, where everything is in network attached storage, and Linux
is fighting its way in. Pathname based access control gives you much
finer granularity of access control on which NFS mounted files an
application can access.

Note that the insecurity of NFS due to lack of authentication is
irrelevant here. Access controls on an NFS server would be insecure
because the clients are spoofable. However, what AppArmor does is
constrain an application on the NFS client with respect to which
*imported* files it can access.

> 2) Files that are dynamically created/deleted(inode number is not fixed).
>    Example is files on /tmp and /etc/mtab. SELinux Policy Editor is
> using file type transition to configure access control for them.
>   
This also is an important distinction. AppArmor can specify policy for
files that don't exist yet. SELinux can specify policy for files that
don't exist yet, but only in so far as you can write TE rules for labels
that do exist, and will be applied to the files when they are created.

Suppose we want to write a profile for fingerd. In AppArmor, the rule
would be "/home/*/.plan r" to grant read access to everyone's .plan
file. Some people don't have a .plan file, but they do create them ad
hoc as time goes on. What does seedit do in that case?

A more problematic case in classic SELinux is personal public_html
directories
http://fedora.redhat.com/docs/selinux-apache-fc3/sn-simple-setup.html

The goal is to allow Apache to access everyone's public_html directory,
but not the rest of their homedir files. The problem is that each file
can only have a *single* label on it, and so what label to put on
public_html directories and their contents?

    * If you choose user_homedir_t then either
          o Apache cannot access public_html directories at all, or
          o Apache gets access to all user homedir contents, including
            potentially nasty secrets. Not so nice to have your personal
            secrets leaked out through the web server.
    * If you choose httpd_sys_content_t then either
          o Users cannot access their own public_html directories, which
            is useless, or
          o Users can write to the system web pages, which means any
            user can change the system home page.

None of the above alternatives are pretty. To solve this problem in a
labeled system, you would have to have some way of attaching more than
one label to a single file. You can fake that by creating a software MUX
that encodes multiple labels into a single label, but that creates an
explosion in the number of labels. You have to have a new MUX for every
system daemon that needs to access homedir contents. There is also the
problem that the public_html directory might be removed and re-created
by the user, resulting in it automatically inheriting the user_homedir_t
label.

This page http://fedora.redhat.com/docs/selinux-faq-fc5/#id2978458
solves the problem by labeling public_html with httpd_user_content_t.
This eliminates the need for a MUX by applying the same label to all
user public_html directories. But it is unclear which applications can
author httpd_user_content_t content -- and i'm not sure if users are
allowed to relabel their files.

Or you can use an AppArmor rule of "/home/*/public_html/** r".

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Yuichi Nakamura]

On Wed, 19 Apr 2006 14:10:39 -0700
Crispin Cowan wrote:
> Does it label the file system as well? If not, then the path names you
> can specify with different access rights would be very limited. If so,
> then any change to the policy requires a relabellings.
Yes, files are labeled.
We make diff between before modification and after modification, 
and relabeles only files whose label definition have changed.
So it does not take much time to relabel.
 
> More than just sysfs. All network attached storage (NFS mounted file
> systems) cannot support xattr. One could imagine supporting xattr for
> Linux-based NFS servers, but that just won't work for non-linux storage
> servers.
I think it is correct.

> Suppose we want to write a profile for fingerd. In AppArmor, the rule
> would be "/home/*/.plan r" to grant read access to everyone's .plan
> file. Some people don't have a .plan file, but they do create them ad
> hoc as time goes on. What does seedit do in that case?
Now seedit can not resolve this by itself.
One solution is to watch file creation by "restorecond".
(restorecond: http://danwalsh.livejournal.com/4368.html)
But we have to create list of possible file names.

---
Yuichi Nakamura

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Karl MacMillan]

On Wed, 2006-04-19 at 14:10 -0700, Crispin Cowan wrote:

<snip>

> A more problematic case in classic SELinux is personal public_html
> directories
> http://fedora.redhat.com/docs/selinux-apache-fc3/sn-simple-setup.html
> 
> The goal is to allow Apache to access everyone's public_html directory,
> but not the rest of their homedir files. The problem is that each file
> can only have a *single* label on it, and so what label to put on
> public_html directories and their contents?
> 
>     * If you choose user_homedir_t then either
>           o Apache cannot access public_html directories at all, or
>           o Apache gets access to all user homedir contents, including
>             potentially nasty secrets. Not so nice to have your personal
>             secrets leaked out through the web server.
>     * If you choose httpd_sys_content_t then either
>           o Users cannot access their own public_html directories, which
>             is useless, or
>           o Users can write to the system web pages, which means any
>             user can change the system home page.
> 

You seem to be freely switching between describing the targeted and
strict policies here (the link is describing targeted and your example
implies strict), ending up with a description that is not accurate for
either. On a targeted FC5 system httpd_sys_content_t works for users web
pages and SELinux makes no attempt to limit the editing of the files by
the users because they are unconfined. Users are, of course, still
subject to DAC permissions.

With a strict policy it is a simple matter to label user web pages with
httpd_user_content_t (see below) and system web pages with
httpd_sys_content_t and have SELinux determine which users can edit the
system web pages by role. I don't see how the same could be accomplished
with App Armor, so it is strange that you are trying to portray this as
a weakness in SELinux.

> None of the above alternatives are pretty. To solve this problem in a
> labeled system, you would have to have some way of attaching more than
> one label to a single file. You can fake that by creating a software MUX
> that encodes multiple labels into a single label, but that creates an
> explosion in the number of labels. You have to have a new MUX for every
> system daemon that needs to access homedir contents. There is also the
> problem that the public_html directory might be removed and re-created
> by the user, resulting in it automatically inheriting the user_homedir_t
> label.
> 
> This page http://fedora.redhat.com/docs/selinux-faq-fc5/#id2978458
> solves the problem by labeling public_html with httpd_user_content_t.
> This eliminates the need for a MUX by applying the same label to all
> user public_html directories. But it is unclear which applications can
> author httpd_user_content_t content -- and i'm not sure if users are
> allowed to relabel their files.
> 
> Or you can use an AppArmor rule of "/home/*/public_html/** r".
> 

I'm not certain where you came up with this straw man, but arguing that
SELinux is hard because things don't work when you label user's public
html files with types not intended for that purpose is somewhat
surprising.

Following the directions in the faq entry you link to on a FC5 system
works perfectly well for me. Not certain why you are confused about
whether users are allowed to do this relabeling since the faq explicitly
shows how to do this and includes an example session where it
successfully works. As for which applications can edit that type a) most
user applications are unconfined so they will work and b) the question
is easy to answer with any policy analysis tool like Apol or examining
the policy manually.

I would also note that no policy development was needed to enable user
web pages, which I think much easier regardless of how simple the policy
language 

If you want to know why SELinux does not support multiple contexts per
object (by design) there is a long discussion start at
http://www.nsa.gov/selinux/list-archive/0501/thread_body50.cfm.

Karl

> Crispin

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Tue, 2006-04-18 at 23:38 +0200, Kurt Garloff wrote:
> Hi,
> 
> On Tue, Apr 18, 2006 at 12:58:19PM +0100, Christoph Hellwig wrote:
> > It's doing access control on pathnames, which can't work in unix enviroments.
> > It's following the default permit behaviour which causes pain in anything
> > security-related (compare [1]).
> 
> Pathnames are problematic, no doubt.
> So AppArmor does currently do some less-than-nice things to get around
> this.
> On the other side, pathnames is what the admins see and use, so it is
> the right abstraction for the sysadmin, if you want to make a higher
> level of security available to people without the need to get them
> a large amount of extra training.
> So that gap needs to be bridged somehow.

The gap should be bridged in userspace.  Not by having the kernel rely
on pathnames.

> Maybe there are better ways compared to what AA does currently, and
> constructive suggestions are very welcome!
> 
> And no, just claiming that AA is useless or crap is not constructive
> AFAICT. And saying that is should be better done as part of SElinux
> is not either.
> 
> The goals are quite different. SElinux is a solution that wants to
> implement policies that cover lots of things. It's accordingly powerful
> and complex.

Sorry, what precisely does AppArmor want to do?  SELinux wants to
provide a mechanism that can support higher level confidentiality and
integrity goals with _confidence_ and can support application security
requirements as well (recognizing that security doesn't end with the
OS).

> AppArmor is easy. Everyone with a little background in Un*x can
> understand what it does and how it needs to be configured.
> Eventually, most sysadmins of the world can configure it correctly
> and thus make their systems more secure.

Userspace, userspace, userspace.  That is where ease-of-use is handled.
Making their systems more secure is open to debate.  And remember that
if ease-of-use is your sole or primary criteria, then anyone can always
beat AppArmor at that game.

> I don't want to judge, but I think the approaches and goals are 
> different enough to grant both (and evetually others) the right 
> to live.
> 
> Actually, I'm a bit worried about the discussion.
> When I chose Linux, it was about the freedom of choice.
> And we have a nice abstraction (LSM) that allows this freedom. At
> a small price. It's not pleasant to see that some people want to move
> away from that.

I've seen no shortage of times on linux-fsdevel and linux-kernel where a
kernel developer has explained to someone that trying to rely on
pathnames is broken.  Why should AppArmor be exempted from the same
criteria?  And even if we assume that pathnames are a sound basis, it is
very clear from the code (last I looked) that LSM is not a good fit for
what AppArmor is trying to do, so why should AppArmor be using LSM?
  
-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Mon, 2006-04-17 at 18:44 -0700, Gerrit Huizenga wrote:
> On Mon, 17 Apr 2006 23:55:25 BST, Christoph Hellwig wrote:
> > On Mon, Apr 17, 2006 at 03:15:29PM -0700, Gerrit Huizenga wrote:
> > > configure correctly that most of them disable it.  In theory, LSM +
> > > something like AppArmour provides a much simpler security model for
> > 
> > apparmor falls into the findamentally broken category above, so it's
> > totally uninteresting except as marketing candy for the big red company.
> 
> Is there a pointer to why it is fundamentally broken?  I haven't seen
> such comments before but it may be that I've been hanging out on the
> wrong lists or spending too much time inhaling air at 30,000 feet.

See the last para of the Useability discussion from the SELinux summit
minutes:
http://www.selinux-symposium.org/2006/summit.php
(re a proposal for pathname-based configuration in SELinux, and why it isn't a good idea)

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Chris Wright]

* Gerrit Huizenga (gh@us.ibm.com) wrote:
> I get the impression from customers that SELinux is so painful to
> configure correctly that most of them disable it.  In theory, LSM +
> something like AppArmour provides a much simpler security model for
> normal human beings who want some level of configuration.  Also,
> the current SELinux config in RH is starting to have a measureable
> performance impact.  I'm not sure this particular battle of the
> security models is quite over from a real user perspective.

SELinux usability is not the same issue as having LSM in the kernel.
So, I agree, usability can improve, but having AppArmor as external
patchkit is not helping show LSM is needed in upstream tree.  It needs
to survive review and get upstream as a means to showing the use of LSM.

thanks,
-chris

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley]

On Mon, 2006-04-17 at 14:26 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > Then provide a counterexample.
> 
> Hopefully a new version of evm+slim+ima will be ready for distribution
> soon.

IIRC, upon their last submission (at which time they were severely
broken in design and implementation), it was demonstrated that they
didn't make sense as separate LSMs, and that their separation was
actually harmful to a correct and efficient implementation.

-- 
Stephen Smalley
National Security Agency

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Kazuki Omo(Company)]

Hi,

This is my first post. My name is OMO, member of LIDS development team.
(LIDS is not IDS. I think the name sometime will cause
 misunderstanding.)

Actually, LIDS is using LSM Framework from kernel-2.6.0 and
keeps developing new one.
http://marc.theaimsgroup.com/?l=linux-security-module&m=113472048023966&w=2

OMO

Stephen Smalley wrote: (2006/04/18 03:15):
> On Mon, 2006-04-17 at 11:02 -0700, Casey Schaufler wrote:
> 
>>--- Christoph Hellwig <hch@infradead.org> wrote:
>>
>>
>>>>Or, better, remove LSM itself ;)
>>>
>>>Seriously that makes a lot of sense.  All other
>>>modules people have come up
>>>with over the last years are irrelevant and/or
>>>broken by design.
>>
>>Didn't you mean "Bah!" (waves paw)?
>>
>>I understand the enthusiasm that the SELinux
>>following demonstrates for the technology.
>>I do not appreciate the bashing of alternatives.
> 
> 
> Then provide a counterexample.
> 


-- 
Kazuki Omo: k-omo@10art-ni.co.jp
Group Manager, OSS Technology Group, Linux Technology
LIDS Japanese Information:
Japanese: http://www.selinux.gr.jp/LIDS-JP/index.html
English:  http://www.selinux.gr.jp/LIDS-JP/LIDS_en/index.html

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[James Morris]

On Tue, 18 Apr 2006, Kazuki Omo(Company) wrote:

> This is my first post. My name is OMO, member of LIDS development team.
> (LIDS is not IDS. I think the name sometime will cause
>  misunderstanding.)
> 
> Actually, LIDS is using LSM Framework from kernel-2.6.0 and
> keeps developing new one.
> http://marc.theaimsgroup.com/?l=linux-security-module&m=113472048023966&w=2


This is out of tree code, and thus typically not considered in the 
mainline development process.


- James
-- 
James Morris
<jmorris@namei.org>

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Greg KH]

On Tue, Apr 18, 2006 at 10:05:44PM +0900, Kazuki Omo(Company) wrote:
> Hi,
> 
> This is my first post. My name is OMO, member of LIDS development team.
> (LIDS is not IDS. I think the name sometime will cause
>  misunderstanding.)
> 
> Actually, LIDS is using LSM Framework from kernel-2.6.0 and
> keeps developing new one.
> http://marc.theaimsgroup.com/?l=linux-security-module&m=113472048023966&w=2

That's great.  But why haven't you submitted LIDS for acceptance into
the main kernel tree?

thanks,

greg k-h

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Casey Schaufler]

--- Greg KH <greg@kroah.com> wrote:


> That's great.  But why haven't you submitted LIDS
> for acceptance into the main kernel tree?

Perhaps a pointer to instructions on how
one might go about doing so would be helpful.


Casey Schaufler
casey@schaufler-ca.com

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Greg KH]

On Tue, Apr 18, 2006 at 08:51:47AM -0700, Casey Schaufler wrote:
> 
> --- Greg KH <greg@kroah.com> wrote:
> 
> 
> > That's great.  But why haven't you submitted LIDS
> > for acceptance into the main kernel tree?
> 
> Perhaps a pointer to instructions on how
> one might go about doing so would be helpful.

Documentation/SubmittingPatches is almost everything you need to know on
how to submit a patch for inclusion in the kernel source tree.
Documentation/HOWTO is also a good place to start with, as it has a few
pointers to other locations in the Documentation tree, and on the web,
for things to read on how to do this.

Hope this helps,

greg k-h

Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[James Morris]

On Mon, 17 Apr 2006, Christoph Hellwig wrote:

> > Or, better, remove LSM itself ;)
> 
> Seriously that makes a lot of sense.  All other modules people have come up
> with over the last years are irrelevant and/or broken by design.

It's been nearly a year since I proposed this, and we've not seen any 
appropriate LSM modules submitted in that time.

See
http://thread.gmane.org/gmane.linux.kernel.lsm/1120
http://thread.gmane.org/gmane.linux.kernel.lsm/1088

The only reason I can see to not delete it immediately is to give BSD 
secure levels users a heads-up, although I thought it was already slated 
for removal.  BSD secure levels is fundamentally broken and should 
never have gone into mainline.

How about enough time to get us to 2.6.18, say, two months?


Signed-off-by: James Morris <jmorris@namei.org>

--- linux-2.6.17-rc1.o/Documentation/feature-removal-schedule.txt	2006-04-15 19:57:53.000000000 -0400
+++ linux-2.6.17-rc1.x/Documentation/feature-removal-schedule.txt	2006-04-17 15:18:15.000000000 -0400
@@ -246,3 +246,27 @@ Why:	The interface no longer has any cal
 Who:	Nick Piggin <npiggin@suse.de>
 
 ---------------------------
+
+What:	LSM (Linux Security Modules) including BSD Secure Levels.
+When:	June 2006
+Why:	In the years since LSM was included in the mainline kernel, SELinux
+        has been the only significant module implemented and also included
+        in the mainline kernel.  So we have a generalized framework for
+        one user, SELinux, which itself is a generalized framework.
+        Thus, LSM will be removed, as it adds unecessary infrastructure,
+        performance overhead and complicates the code.  It also attracts
+        a regular stream of misconceived and broken security module
+        submissions to mainline, such as BSD Security Levels, and
+        developers are seeing LSM as the answer to everything rather
+        than really thinking about what they need and how to architect
+        the code properly and generally.  There is also a growing number
+        of proprietary modules hooking into LSM in usafe ways, not 
+        necessarily even for security purposes.  The LSM interface
+        semantics are too weak and such an API does not belong in the
+        mainline kernel.
+        See also, previous discussions on the issue:
+        http://thread.gmane.org/gmane.linux.kernel.lsm/1120
+        http://thread.gmane.org/gmane.linux.kernel.lsm/1088
+Who:	James Morris <jmorris@namei.org>
+
+---------------------------

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Greg KH]

On Mon, Apr 17, 2006 at 03:20:55PM -0400, James Morris wrote:
> On Mon, 17 Apr 2006, Christoph Hellwig wrote:
> 
> > > Or, better, remove LSM itself ;)
> > 
> > Seriously that makes a lot of sense.  All other modules people have come up
> > with over the last years are irrelevant and/or broken by design.
> 
> It's been nearly a year since I proposed this, and we've not seen any 
> appropriate LSM modules submitted in that time.
> 
> See
> http://thread.gmane.org/gmane.linux.kernel.lsm/1120
> http://thread.gmane.org/gmane.linux.kernel.lsm/1088
> 
> The only reason I can see to not delete it immediately is to give BSD 
> secure levels users a heads-up, although I thought it was already slated 
> for removal.  BSD secure levels is fundamentally broken and should 
> never have gone into mainline.

I agree about the BSD secure levels code, it has a known reported
security problem, with no response by its maintainers.  On that aspect
alone, it should be removed.

But for removing LSM entirely, I'm starting to like your patch.  It's
been a very long time and so far, only out-of-tree LSMs are present,
with no public statements about getting them submitted into the main
kernel tree.  And, I think almost all of the out-of-tree modules already
need other kernel patches to get their code working properly, so what's
a few more hooks needed...

/me pokes the bushes to flush out the people lurking

Oh, but do remember, the main goal of LSM was to stop people from
arguing about different security models.  Now that it is in, we haven't
had any bickering about different types of things that should go into
mainline, all with different models and usages.  Everyone gets to play
in their own sandbox and not worry about anyone else.  If the LSM
interface was to go away, that problem would start happening again, and
I don't think we want to go there.

So, I think the only way to be able to realisticly keep the LSM
interface, is for a valid, working, maintained LSM-based security model
to go into the kernel tree.  So far, I haven't seen any public posting
of patches that meet this requirement :(

thanks,

greg k-h

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

> 
> But for removing LSM entirely, I'm starting to like your patch.  It's
> been a very long time and so far, only out-of-tree LSMs are present,
> with no public statements about getting them submitted into the main
> kernel tree.  And, I think almost all of the out-of-tree modules already
> need other kernel patches to get their code working properly, so what's
> a few more hooks needed...

and if it really cripples the one real user of the API.. then it's
clearly a wrong thing and it should be fixed (by going away and going
direct instead).

As for your argument about the bickering... well... afaics most of the
people who originally in the game quietly went away once it was clear
that LSM exports were _GPL only .. or when their modules were reviewed
and shown to be architecturally broken.

Who's left today?

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Alan Cox]

On Llu, 2006-04-17 at 12:51 -0700, Greg KH wrote:
> I agree about the BSD secure levels code, it has a known reported
> security problem, with no response by its maintainers.  On that aspect
> alone, it should be removed.

You can implement a BSD securelevel model in SELinux as far as I can see
from looking at it, and do it better than the code today, so its not
really a feature drop anyway just a migration away from some fossils

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Casey Schaufler]

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> You can implement a BSD securelevel model in SELinux
> as far as I can see
> from looking at it,

Well, to seriously mangle quotes,
you can implement any policy you want
with SELinux, so long as Tresys puts
it in.

> and do it better than the code today, so its not
> really a feature drop anyway just a migration away
> from some fossils

Dagnabbit, my scales are showing again.

And y'all are right, In tree users of LSM
are a might thin. Sounds as if those who
would use it need to push to get their code
accepted really hard. That means getting
past the inevitable arguement that "you can
do it with SELinux".


Casey Schaufler
casey@schaufler-ca.com

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Mon, 17 Apr 2006 22:26:24 BST, Alan Cox said:

(Two replies to this paragraph, addressing 2 separate issues....)

> You can implement a BSD securelevel model in SELinux as far as I can see
> from looking at it, and do it better than the code today, so its not
> really a feature drop anyway just a migration away from some fossils

If we heave the LSM stuff overboard, there's one thing that *will* need
addressing - what to do with kernel support of Posix-y capabilities.  Currently
some of the heavy lifting is done by security/commoncap.c.

Frankly, that's *another* thing that we need to either *fix* so it works right,
or rip out of the kernel entirely.  As far as I know, there's no in-tree way
to make /usr/bin/ping be set-CAP_NET_RAW and have it DTRT.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu):
> On Mon, 17 Apr 2006 22:26:24 BST, Alan Cox said:
> 
> (Two replies to this paragraph, addressing 2 separate issues....)
> 
> > You can implement a BSD securelevel model in SELinux as far as I can see
> > from looking at it, and do it better than the code today, so its not
> > really a feature drop anyway just a migration away from some fossils
> 
> If we heave the LSM stuff overboard, there's one thing that *will* need
> addressing - what to do with kernel support of Posix-y capabilities.  Currently
> some of the heavy lifting is done by security/commoncap.c.
> 
> Frankly, that's *another* thing that we need to either *fix* so it works right,
> or rip out of the kernel entirely.  As far as I know, there's no in-tree way
> to make /usr/bin/ping be set-CAP_NET_RAW and have it DTRT.

Sigh...  it's such a cool idea, and yet such a dangerously easy thing to
get wrong, ie dropping the ability for a root process to drop it's root
privs.

If we were to drop posix caps, how would selinux change correspondingly?
Would it just drop the capability class altogether, perhaps beef up the
task or security class?  Just wondering whether anyone had thought about
this.

Alternatively, we could try yet again to get support for fs caps
upstream...

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Tue, 2006-04-18 at 07:22 -0500, Serge E. Hallyn wrote:
> Quoting Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu):
> > On Mon, 17 Apr 2006 22:26:24 BST, Alan Cox said:
> > 
> > (Two replies to this paragraph, addressing 2 separate issues....)
> > 
> > > You can implement a BSD securelevel model in SELinux as far as I can see
> > > from looking at it, and do it better than the code today, so its not
> > > really a feature drop anyway just a migration away from some fossils
> > 
> > If we heave the LSM stuff overboard, there's one thing that *will* need
> > addressing - what to do with kernel support of Posix-y capabilities.  Currently
> > some of the heavy lifting is done by security/commoncap.c.
> > 
> > Frankly, that's *another* thing that we need to either *fix* so it works right,
> > or rip out of the kernel entirely.  As far as I know, there's no in-tree way
> > to make /usr/bin/ping be set-CAP_NET_RAW and have it DTRT.

As far as the capability module is concerned, ping can be setuid and can
drop all other capabilities at startup, so you can approximate the
above.  As far as SELinux is concerned, you can bound the capabilities
that ping can exercise based on its security context even if ping runs
as uid 0 and is granted full capabilities by the capability module,
regardless of whether ping ever drops capabilities itself.  So there are
in-tree ways to achieve what you want.

> Sigh...  it's such a cool idea, and yet such a dangerously easy thing to
> get wrong, ie dropping the ability for a root process to drop it's root
> privs.
> 
> If we were to drop posix caps, how would selinux change correspondingly?
> Would it just drop the capability class altogether, perhaps beef up the
> task or security class?  Just wondering whether anyone had thought about
> this.

I doubt you'd drop capability altogether.  You could incrementally
enable the direct granting of capabilities based on SELinux security
context by defining a new class in its policy (cap_override) that
mirrors the existing capability class, and modifying SELinux to
authoritatively grant the capability if it is allowed in that class for
the process' security context; otherwise, you fall back to the existing
combined behavior of requiring both SELinux+capability (or SELinux
+dummy) to grant the capability.  That is simple enough from a code
perspective.  You just need to be careful about the implications for
userspace and policy configuration, to avoid introducing security holes
in this manner.

> Alternatively, we could try yet again to get support for fs caps
> upstream...

Given the extensible nature of the security xattr namespace, it is
already possible to store the capability bits in the filesystem (just by
beginning to use security.effcap, security.inhcap, ...).  The code
modifications to the capability module should be simple.  But modifying
userspace to set and preserve those attributes would take some work,
work which has already been done for the SELinux attributes, and you'd
have to figure out the right set of capability bits for each program,
which doesn't scale very well (vs. using equivalence classes as in
SELinux types).  And the capability evolution logic has always been
problematic, vs. explicit transition definitions as in SELinux.  So fs
caps doesn't seem very promising to me as a path forward.

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Tue, 2006-04-18 at 08:21 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > I doubt you'd drop capability altogether.  You could incrementally
> > enable the direct granting of capabilities based on SELinux security
> > context by defining a new class in its policy (cap_override) that
> > mirrors the existing capability class, and modifying SELinux to
> > authoritatively grant the capability if it is allowed in that class for
> 
> Subject, I hope, to other selinux permission checks!  (ie "authoritatively"
> meaning over dac checks, not over it's own mac checks)

Authoritatively over the capability module is what I meant, i.e. if
capability X is allowed in a new cap_override access vector for the
process' domain, then allow the process to exercise that capability and
skip the call to the secondary module (capability or dummy).  So you
could allow ping_t to exercise that single capability even if it wasn't
uid 0.  But if it is only allowed in the existing capability access
vector and not in the cap_override vector, then only allow it if both
SELinux and the secondary grant it (existing behavior).

Note btw that another reason it is better to do this via SELinux than by
fs caps is that SELinux already provides the right separation/protection
between processes with different security contexts, whereas the
capability module does not (many inter-process interactions are
presently only governed by uid/gid checking).

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Crispin Cowan]

Valdis.Kletnieks@vt.edu wrote:
> If we heave the LSM stuff overboard, there's one thing that *will* need
> addressing - what to do with kernel support of Posix-y capabilities.  Currently
> some of the heavy lifting is done by security/commoncap.c.
>
> Frankly, that's *another* thing that we need to either *fix* so it works right,
> or rip out of the kernel entirely.  As far as I know, there's no in-tree way
> to make /usr/bin/ping be set-CAP_NET_RAW and have it DTRT.
>   
This has actually been one of the interesting developments in AppArmor.
I also had no use for POSIX.1e capabilities; I thought they were so
awkward as to be useless. That is, until we integrated capabilities into
AppArmor profiles.

Consider this profile for /bin/stty
/bin/stty {
  #include <abstractions/base>

  capability sys_tty_config,

  /bin/stty r,
}

This policy basically allows stty to run, read its own text file, and
use the capability sys_tty_config. Even though it may run as root, this
profile confines it to *only* have sys_tty_config.

This gives the system administrator the ability to force applications to
"drop" privs even when the application developer didn't bother, or (as
was the case in a Sendmail vulnerability several years ago) the
application *tried* to drop privs and got it wrong, so was running as
full root anyway.

Capabilities are very easy and natural to use in an AppArmor system. And
they don't require any upstream filesystem support. SELinux provides
similar support for Capabilities, so they are worth keeping even without
upstream filesystem support.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Tue, 18 Apr 2006 13:13:03 PDT, Crispin Cowan said:
> This gives the system administrator the ability to force applications to
> "drop" privs even when the application developer didn't bother, or (as
> was the case in a Sendmail vulnerability several years ago) the
> application *tried* to drop privs and got it wrong, so was running as
> full root anyway.

Interestingly enough, the Sendmail bug was a case where it was forced to "drop"
some privs, and then it didn't have enough privs to drop the rest of the privs.

In other words, it's quite possible to accidentally introduce a vulnerability
that wasn't exploitable before, by artificially restricting the privs in a way
the designer didn't expect.  So this is really just handing the sysadmin
a loaded gun and waiting.

(Incidentally, both SELinux and presumably AppArmor have the same problem - it
is really hard to convince yourself that you've identified *all* the access that
a given program needs.  People keep finding ways to excersize previously untested
code paths and error handlers, resulting in a game of whack-a-mole as the program
fails due to a lack of permissions.  This is especially fun to debug when the
program is already in an error handler... ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Crispin Cowan]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 18 Apr 2006 13:13:03 PDT, Crispin Cowan said:
>   
>> This gives the system administrator the ability to force applications to
>> "drop" privs even when the application developer didn't bother, or (as
>> was the case in a Sendmail vulnerability several years ago) the
>> application *tried* to drop privs and got it wrong, so was running as
>> full root anyway.
>>     
> Interestingly enough, the Sendmail bug was a case where it was forced to "drop"
> some privs, and then it didn't have enough privs to drop the rest of the privs.
>
> In other words, it's quite possible to accidentally introduce a vulnerability
> that wasn't exploitable before, by artificially restricting the privs in a way
> the designer didn't expect.  So this is really just handing the sysadmin
> a loaded gun and waiting.
>   
While that is true of the voluntary model of acquiring and dropping
privs, it is not true of AppArmor containment, which will just not give
you the priv if it is not in your policy.

> (Incidentally, both SELinux and presumably AppArmor have the same problem - it
> is really hard to convince yourself that you've identified *all* the access that
> a given program needs.  People keep finding ways to excersize previously untested
> code paths and error handlers, resulting in a game of whack-a-mole as the program
> fails due to a lack of permissions.  This is especially fun to debug when the
> program is already in an error handler... ;)
>   
That is true: both SELinux and AppArmor use a white list within a single
application policy (for the Targeted Policy) leading to this problem.

White lists have the property of being highly secure, but a big pain in
the ass because they *must* be complete, and you shoot yourself in the
foot if they are not. Black lists are the exact dual; relatively
insecure, and relatively easy to use.

AppArmor uses a hybrid white list/black list approach:

    * Per profile, it is white list: when we confine a program, we
      specify every file and POSIX.1e Capability that it can access.
      This includes an inheritance model, so that all of the children
      that it forks are also confined by policy; what they can exec() is
      controlled.
    * System-wide it is black-list: only programs with an explicit
      policy are confined. However, because of the inheritance model,
      confined programs cannot escape by just exec()'ing some program
      that is not normally confined: AppArmor controls what you can
      exec, and thus controls what other policies you can transition to.

AppArmor also aggressively uses wildcards in policy generation, so you
can e.g. grant "/etc/apache2/** r" and "/srv/www/htdocs/** r" to Apache,
and then not have to care whether you fully exercised all of Apache's
configurations and hit all of the web pages.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Wed, 19 Apr 2006 17:19:04 PDT, Crispin Cowan said:
> Valdis.Kletnieks@vt.edu wrote:
> > In other words, it's quite possible to accidentally introduce a vulnerability
> > that wasn't exploitable before, by artificially restricting the privs in a way
> > the designer didn't expect.  So this is really just handing the sysadmin
> > a loaded gun and waiting.
> >   
> While that is true of the voluntary model of acquiring and dropping
> privs, it is not true of AppArmor containment, which will just not give
> you the priv if it is not in your policy.

The threat model is that you can take a buggy application, and constrain its
access to priv A in a way that causes a code failure that allows you to abuse
an unconstrained priv B.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Ken Brush]

On 4/20/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Wed, 19 Apr 2006 17:19:04 PDT, Crispin Cowan said:
> > Valdis.Kletnieks@vt.edu wrote:
> > > In other words, it's quite possible to accidentally introduce a vulnerability
> > > that wasn't exploitable before, by artificially restricting the privs in a way
> > > the designer didn't expect.  So this is really just handing the sysadmin
> > > a loaded gun and waiting.
> > >
> > While that is true of the voluntary model of acquiring and dropping
> > privs, it is not true of AppArmor containment, which will just not give
> > you the priv if it is not in your policy.
>
> The threat model is that you can take a buggy application, and constrain its
> access to priv A in a way that causes a code failure that allows you to abuse
> an unconstrained priv B.

So you are talking about a 2 prong attack. One in where you somehow
trick program A to do something that it's allowed to. That then would
cause an error in program B ? Or cause program B to do something
wonky.

I guess a good example of this would be if you sent an email to
sendmail (which is constrained) to write the message to my mailbox
(which is allowed, obviously).

Then I use an imap daemon (which would not be constrained, in the
hypothetical, personally I constrain everything I can). To retrieve
that message but the payload of the message causes the imap daemon to
delete /lib ?

Is that a proper example? or do you mean something else?

-Ken

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

On Fri, 21 Apr 2006 08:23:51 PDT, Ken Brush said:
> On 4/20/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> > On Wed, 19 Apr 2006 17:19:04 PDT, Crispin Cowan said:
> > > Valdis.Kletnieks@vt.edu wrote:
> > The threat model is that you can take a buggy application, and constrain its
> > access to priv A in a way that causes a code failure that allows you to abuse
> > an unconstrained priv B.
> 
> So you are talking about a 2 prong attack. One in where you somehow
> trick program A to do something that it's allowed to. That then would
> cause an error in program B ? Or cause program B to do something
> wonky.

No, it's a two prong attack against *one* program.  For instance, the Sendmail
bug - the attack A was to cripple its ability to drop privs, which then exposed
it to abuse B of running at a higher priv than it should have.

The crucial point here is that the attacker is trying to gain access to
(for instance) the ability to write to any file, but gets there by crippling
some *other* priv.

Another (totally made up theoretical, hopefully) Sendmail-ish example would be
to artificially constrain it's ability to open port 25 for listening, and then
using a symlink attack to redirect its complaint "I can't open 25" to trash
some file you can't read/write yourself....

The reason that this is such a can-of-worms security wise is that the vast majority
of programs have *not* had sufficient auditing of their error-handling code.
As a result, blindly applying a privilege constraint to clip off some priv A
that the policy writer doesn't think is needed can "load a round in the chamber"
for a clever attacker to abuse.

(Note that this concern applies equally to AppArmor and SELinux and almost any
other constraint-based system.  It's merely more *likely* to bite AppArmor
based systems, because it's marketing itself as "user/sysadmin friendly" - and
thus more likely to attract people trying to secure their system without real
understanding.  You don't get many problems with SELinux down this path,
because most SELinux people already have a mindset that "Even with proper
tools, writing a policy is hard and requires some careful thought/analysis"...)




[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Ken Brush]

On 4/21/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Fri, 21 Apr 2006 08:23:51 PDT, Ken Brush said:
> > On 4/20/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> > > On Wed, 19 Apr 2006 17:19:04 PDT, Crispin Cowan said:
> > > > Valdis.Kletnieks@vt.edu wrote:
> > > The threat model is that you can take a buggy application, and constrain its
> > > access to priv A in a way that causes a code failure that allows you to abuse
> > > an unconstrained priv B.
> >
> > So you are talking about a 2 prong attack. One in where you somehow
> > trick program A to do something that it's allowed to. That then would
> > cause an error in program B ? Or cause program B to do something
> > wonky.
>
> No, it's a two prong attack against *one* program.  For instance, the Sendmail
> bug - the attack A was to cripple its ability to drop privs, which then exposed
> it to abuse B of running at a higher priv than it should have.
>
> The crucial point here is that the attacker is trying to gain access to
> (for instance) the ability to write to any file, but gets there by crippling
> some *other* priv.
>

It's nearly impossible for an access control mechanism to analyze a
program and figure out what it's trying to do.  The whole program
would be constrained with what it would be allowed to do in it's
entirety.  Systems like postfix can be constrained more effectively,
since each individual program would have a tighter policy on what it
can do.

If you can point me to an access control mechanism that could stop
what you describe, I would be very interested in it.

> Another (totally made up theoretical, hopefully) Sendmail-ish example would be
> to artificially constrain it's ability to open port 25 for listening, and then
> using a symlink attack to redirect its complaint "I can't open 25" to trash
> some file you can't read/write yourself....
>
> The reason that this is such a can-of-worms security wise is that the vast majority
> of programs have *not* had sufficient auditing of their error-handling code.
> As a result, blindly applying a privilege constraint to clip off some priv A
> that the policy writer doesn't think is needed can "load a round in the chamber"
> for a clever attacker to abuse.

This is where you try to cover these mistakes with compiler tools like
Propolice.

> (Note that this concern applies equally to AppArmor and SELinux and almost any
> other constraint-based system.  It's merely more *likely* to bite AppArmor
> based systems, because it's marketing itself as "user/sysadmin friendly" - and
> thus more likely to attract people trying to secure their system without real
> understanding.  You don't get many problems with SELinux down this path,
> because most SELinux people already have a mindset that "Even with proper
> tools, writing a policy is hard and requires some careful thought/analysis"...)

So, because SELinux is harder to configure. When it's exploited no one
is surprised?
Or what is your exact argument?

That sysadmins are not sophisticated enough to properly configure the
MAC systems AppArmor and SELinux effectively? Or that people who use
AppArmor are not likely to put careful thought into the policies that
they use?

-Ken

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

On Sat, 22 Apr 2006 13:52:57 PDT, Ken Brush said:
> That sysadmins are not sophisticated enough to properly configure the
> MAC systems AppArmor and SELinux effectively?

We know they're usually not.  There are a *few* that have a clue, but most
don't.  And as the Linux market grows, we're going to have more and more Linux
sysadmins with less than a year's experience...

>                                                Or that people who use
> AppArmor are not likely to put careful thought into the policies that
> they use?

They're not likely to put careful thought into it, *AND* that saying things
like "AppArmor is so *simple* to configure" only makes things worse - this
encourages unqualified people to create broken policy configurations.

I have no problem with "handles a lot of the grunt work so an
expert can write policy quicker" - there's people working on policy
editors for SELinux that address this as well.  It is however a dis-service
to conflate this with "makes it easy for non-experts to write policy".  Yes,
they may be able to "write policy" easily.  The question is whether it
enables then to "write *correct* policy" (easily, or at all).....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Lars Marowsky-Bree]

On 2006-04-23T05:45:34, Valdis.Kletnieks@vt.edu wrote:

> > AppArmor are not likely to put careful thought into the policies that
> > they use?
> They're not likely to put careful thought into it, *AND* that saying things
> like "AppArmor is so *simple* to configure" only makes things worse - this
> encourages unqualified people to create broken policy configurations.

That is about the dumbest argument I've heard so far, sorry. With the
same argument, these people shouldn't be allowed to admin any computer
system and be given a broom to wipe the floor, and let the experts take
care of the world for them.

Now that's a perfectly reasonable line of thought, and I've most
certainly had it when it comes to HA and clusters myself, but in no
means is it a good reasoning against the _technology_. If it is simpler
to use, it will be simpler to use even for smart people, who can then
put more care into their security profiles instead of worrying about the
complexity.



-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Alan Cox]

On Llu, 2006-04-24 at 10:24 +0200, Lars Marowsky-Bree wrote:
> On 2006-04-23T05:45:34, Valdis.Kletnieks@vt.edu wrote:
> 
> > > AppArmor are not likely to put careful thought into the policies that
> > > they use?
> > They're not likely to put careful thought into it, *AND* that saying things
> > like "AppArmor is so *simple* to configure" only makes things worse - this
> > encourages unqualified people to create broken policy configurations.
> 
> That is about the dumbest argument I've heard so far, sorry. 

Its the conclusion of most security experts I know that broken security
is worse than no security at all. 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Lars Marowsky-Bree]

On 2006-04-24T13:42:31, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > That is about the dumbest argument I've heard so far, sorry. 
> Its the conclusion of most security experts I know that broken security
> is worse than no security at all. 

That would be the case of a security model the admin doesn't understand,
either because it is too complex (SELinux) or because it is too simple
as to invite sloppishness (AA), according to which side you ask. Hard
call.


Sincerely,
    Lars Marowsky-Brée

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Olivier Galibert]

On Mon, Apr 24, 2006 at 01:42:31PM +0100, Alan Cox wrote:
> On Llu, 2006-04-24 at 10:24 +0200, Lars Marowsky-Bree wrote:
> > On 2006-04-23T05:45:34, Valdis.Kletnieks@vt.edu wrote:
> > 
> > > > AppArmor are not likely to put careful thought into the policies that
> > > > they use?
> > > They're not likely to put careful thought into it, *AND* that saying things
> > > like "AppArmor is so *simple* to configure" only makes things worse - this
> > > encourages unqualified people to create broken policy configurations.
> > 
> > That is about the dumbest argument I've heard so far, sorry. 
> 
> Its the conclusion of most security experts I know that broken security
> is worse than no security at all. 

While that may be true[1], it gets a little annoying when broken is
meant to be synonymous to "not the SELinux model".  Especially since
there are aspects where SELinux' security can be considered broken,
complexity being one of them, crappy failure modes being another,
handling of new files a third, handling of namespaces a fourth.

Paths vs. inodes is religion, nothing else.  There are arguments for
and against on both sides.  LSM was supposed to be inclusive of all
beliefs, has that changed?

  OG.

[1] Why do we have uis and permission bits already?  After all, it's
not perfect hence broken, right?

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

> While that may be true[1], it gets a little annoying when broken is
> meant to be synonymous to "not the SELinux model".  Especially since
> there are aspects where SELinux' security can be considered broken,
> complexity being one of them, crappy failure modes being another,
> handling of new files a third, handling of namespaces a fourth.

while I agree with the first three arguments, handling of namespaces
isn't  fundamental SELinux weakness.


> Paths vs. inodes is religion, nothing else. 

Actually I think you're wrong on that. Paths are more fragile, even the
AppArmor people will admit that. They just think they can get away with
it by closing a dozen+ ways of cheating with that and by limiting the
scope of the security model. 

Maybe the question "is the fragility worth it" is a religious question,
but the fundamental truth is that an inodes approach is by far more
robust and beyond such "nothing else" statement.

>   LSM was supposed to be inclusive of all
> beliefs, has that changed?

until last week SELinux was the only user of LSM. You can't fault LSM
for not facilitate all the unwritten code that is possible in the world.
And to some degree I would question the feasability of having ONE model
for all such things in the first place. In fact, we already know that to
do auditing, LSM is the wrong thing to do (and that's why audit doesn't
use LSM). It's one of those fundamental linux truths: Trying to be
everything for everyone leads to crappy interfaces.

Now that there's a second proposed user, the real evaluation of the
value of LSM can be made in this regard, and if the consensus is that
it's fixable, the interfaces can be cleaned up to facilitate both
SELinux and AppArmor. But I don't think you can a priori say that LSM is
the right answer, given that AppArmor seems to highly struggle with it,
nor do I think it HAS to be. I rather have separate interfaces for
AppArmor and SELinux than one, bad, joint interface that everyone hates.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Arjan van de Ven (arjan@infradead.org):
> for all such things in the first place. In fact, we already know that to
> do auditing, LSM is the wrong thing to do (and that's why audit doesn't
> use LSM). It's one of those fundamental linux truths: Trying to be

As I recall it was simply decided that LSM must be "access control
only", and that was why it wasn't used for audit.

Didn't Linda Walsh claim a much faster audit implementation using LSM
than the current lightweight audit framework?

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-24 at 08:09 -0500, Serge E. Hallyn wrote:
> Quoting Arjan van de Ven (arjan@infradead.org):
> > for all such things in the first place. In fact, we already know that to
> > do auditing, LSM is the wrong thing to do (and that's why audit doesn't
> > use LSM). It's one of those fundamental linux truths: Trying to be
> 
> As I recall it was simply decided that LSM must be "access control
> only", and that was why it wasn't used for audit.

no you recall incorrectly.
Audit needs to audit things that didn't work out, like filenames that
don't exist. Audit needs to know what is going to happen before the
entire "is this allowed" chain is going to be followed. SELInux and
other LSM parts are just one part of that chain, and there's zero
guarantee that you get to the LSM part in the chain.....  Now of course
you could add hooks at places where audit puts them now, and call those
"LSM" but that'd just be artificial, pointless and bad design.


> Didn't Linda Walsh claim a much faster audit implementation using LSM
> than the current lightweight audit framework?

People can claim the world; the problem is that you can't make a tight
audit with LSM because of all the namespace issues (AppArmor can evade
those by locking stuff down, audit obviously cannot). So I highly doubt
the validity of such claim.
Audit also HAS to tie into some other places to avoid having to
double-copy on the userspace filename data, at which point you're not
really using LSM, you're just hijacking some of it's hooks.
[and you have to avoid such double copy for your audit to be reliable
enough to mean something]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Arjan van de Ven (arjan@infradead.org):
> On Mon, 2006-04-24 at 08:09 -0500, Serge E. Hallyn wrote:
> > Quoting Arjan van de Ven (arjan@infradead.org):
> > > for all such things in the first place. In fact, we already know that to
> > > do auditing, LSM is the wrong thing to do (and that's why audit doesn't
> > > use LSM). It's one of those fundamental linux truths: Trying to be
> > 
> > As I recall it was simply decided that LSM must be "access control
> > only", and that was why it wasn't used for audit.
> 
> no you recall incorrectly.
> Audit needs to audit things that didn't work out, like filenames that
> don't exist. Audit needs to know what is going to happen before the
> entire "is this allowed" chain is going to be followed. SELInux and
> other LSM parts are just one part of that chain, and there's zero
> guarantee that you get to the LSM part in the chain.....  Now of course

Ah yes.  It needed to be authoritative.  I did recall incorrectly.

I suspect some would argue that you are right that LSM is broken, but
only because it wasn't allowed to be authoritative.  Of course that
was to increase chances of LSM upstream inclusion.  Sorry Casey and
Linda, I bet that just makes it sting all the harder if LSM is now
removed for not being sufficiently useful.

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-24 at 08:29 -0500, Serge E. Hallyn wrote:
> Quoting Arjan van de Ven (arjan@infradead.org):
> > On Mon, 2006-04-24 at 08:09 -0500, Serge E. Hallyn wrote:
> > > Quoting Arjan van de Ven (arjan@infradead.org):
> > > > for all such things in the first place. In fact, we already know that to
> > > > do auditing, LSM is the wrong thing to do (and that's why audit doesn't
> > > > use LSM). It's one of those fundamental linux truths: Trying to be
> > > 
> > > As I recall it was simply decided that LSM must be "access control
> > > only", and that was why it wasn't used for audit.
> > 
> > no you recall incorrectly.
> > Audit needs to audit things that didn't work out, like filenames that
> > don't exist. Audit needs to know what is going to happen before the
> > entire "is this allowed" chain is going to be followed. SELInux and
> > other LSM parts are just one part of that chain, and there's zero
> > guarantee that you get to the LSM part in the chain.....  Now of course
> 
> Ah yes.  It needed to be authoritative.  I did recall incorrectly.
> 
> I suspect some would argue that you are right that LSM is broken, but
> only because it wasn't allowed to be authoritative. 

authoritative isn't enough; think about it. The VFS isn't ever going to
ask "can I open this file" if the file doesn't exist in the first place;
same in many other places. You'd have to almost double the hooks, and as
I said, to call those hooks "LSM" would be silly and dishonest.

LSM is not Hooks-R-Us. It's a permission model. 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Arjan van de Ven (arjan@infradead.org):
> On Mon, 2006-04-24 at 08:29 -0500, Serge E. Hallyn wrote:
> > Quoting Arjan van de Ven (arjan@infradead.org):
> > > On Mon, 2006-04-24 at 08:09 -0500, Serge E. Hallyn wrote:
> > > > Quoting Arjan van de Ven (arjan@infradead.org):
> > > > > for all such things in the first place. In fact, we already know that to
> > > > > do auditing, LSM is the wrong thing to do (and that's why audit doesn't
> > > > > use LSM). It's one of those fundamental linux truths: Trying to be
> > > > 
> > > > As I recall it was simply decided that LSM must be "access control
> > > > only", and that was why it wasn't used for audit.
> > > 
> > > no you recall incorrectly.
> > > Audit needs to audit things that didn't work out, like filenames that
> > > don't exist. Audit needs to know what is going to happen before the
> > > entire "is this allowed" chain is going to be followed. SELInux and
> > > other LSM parts are just one part of that chain, and there's zero
> > > guarantee that you get to the LSM part in the chain.....  Now of course
> > 
> > Ah yes.  It needed to be authoritative.  I did recall incorrectly.
> > 
> > I suspect some would argue that you are right that LSM is broken, but
> > only because it wasn't allowed to be authoritative. 
> 
> authoritative isn't enough; think about it. The VFS isn't ever going to
> ask "can I open this file" if the file doesn't exist in the first place;

Current audit doesn't do that either, does it?  It labels the parent
inode, so if /var/spool/mail doesn't exist, and you look up
/var/spool/mail/hallyn, you won't get an audit record.  You'd have to do
that by auditing all open syscalls at the syscall level.

Unless audit has changed that much in the last few months, which is
possible.

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-24 at 08:54 -0500, Serge E. Hallyn wrote:
> Quoting Arjan van de Ven (arjan@infradead.org):
> > On Mon, 2006-04-24 at 08:29 -0500, Serge E. Hallyn wrote:
> > > Quoting Arjan van de Ven (arjan@infradead.org):
> > > > On Mon, 2006-04-24 at 08:09 -0500, Serge E. Hallyn wrote:
> > > > > Quoting Arjan van de Ven (arjan@infradead.org):
> > > > > > for all such things in the first place. In fact, we already know that to
> > > > > > do auditing, LSM is the wrong thing to do (and that's why audit doesn't
> > > > > > use LSM). It's one of those fundamental linux truths: Trying to be
> > > > > 
> > > > > As I recall it was simply decided that LSM must be "access control
> > > > > only", and that was why it wasn't used for audit.
> > > > 
> > > > no you recall incorrectly.
> > > > Audit needs to audit things that didn't work out, like filenames that
> > > > don't exist. Audit needs to know what is going to happen before the
> > > > entire "is this allowed" chain is going to be followed. SELInux and
> > > > other LSM parts are just one part of that chain, and there's zero
> > > > guarantee that you get to the LSM part in the chain.....  Now of course
> > > 
> > > Ah yes.  It needed to be authoritative.  I did recall incorrectly.
> > > 
> > > I suspect some would argue that you are right that LSM is broken, but
> > > only because it wasn't allowed to be authoritative. 
> > 
> > authoritative isn't enough; think about it. The VFS isn't ever going to
> > ask "can I open this file" if the file doesn't exist in the first place;
> 
> Current audit doesn't do that either, does it?  

As far as I know, it actually does. (assuming you configure it do audit
such events obviously)

> It labels the parent
> inode, so if /var/spool/mail doesn't exist, and you look up
> /var/spool/mail/hallyn, you won't get an audit record. 


>  You'd have to do
> that by auditing all open syscalls at the syscall level.

That's a wrong assumption. There is one level below the syscall level as
well in Linux, and that is where you need to audit for this, and afaik
audit actually does that.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Arjan van de Ven (arjan@infradead.org):
> On Mon, 2006-04-24 at 08:54 -0500, Serge E. Hallyn wrote:
> > Quoting Arjan van de Ven (arjan@infradead.org):
> > > On Mon, 2006-04-24 at 08:29 -0500, Serge E. Hallyn wrote:
> > > > Quoting Arjan van de Ven (arjan@infradead.org):
> > > > > On Mon, 2006-04-24 at 08:09 -0500, Serge E. Hallyn wrote:
> > > > > > Quoting Arjan van de Ven (arjan@infradead.org):
> > > > > > > for all such things in the first place. In fact, we already know that to
> > > > > > > do auditing, LSM is the wrong thing to do (and that's why audit doesn't
> > > > > > > use LSM). It's one of those fundamental linux truths: Trying to be
> > > > > > 
> > > > > > As I recall it was simply decided that LSM must be "access control
> > > > > > only", and that was why it wasn't used for audit.
> > > > > 
> > > > > no you recall incorrectly.
> > > > > Audit needs to audit things that didn't work out, like filenames that
> > > > > don't exist. Audit needs to know what is going to happen before the
> > > > > entire "is this allowed" chain is going to be followed. SELInux and
> > > > > other LSM parts are just one part of that chain, and there's zero
> > > > > guarantee that you get to the LSM part in the chain.....  Now of course
> > > > 
> > > > Ah yes.  It needed to be authoritative.  I did recall incorrectly.
> > > > 
> > > > I suspect some would argue that you are right that LSM is broken, but
> > > > only because it wasn't allowed to be authoritative. 
> > > 
> > > authoritative isn't enough; think about it. The VFS isn't ever going to
> > > ask "can I open this file" if the file doesn't exist in the first place;
> > 
> > Current audit doesn't do that either, does it?  
> 
> As far as I know, it actually does. (assuming you configure it do audit
> such events obviously)

If the parent directory exists, yes.  LSM could do that too.  If the
parent directory does not exist, then you cannot create an audit rule.
I.e. if /var/spool/mail does not exist, you cannot watch
/var/spool/mail/hallyn.  If you have an active rule for
/var/spool/mail/hallyn and you rm -rf /var/spool/mail, the audit rule is
implicitly deleted.  If you then recreate /var/spool/mail, and touch
/var/spool/mail/hallyn, you get no audit entries.

> > It labels the parent
> > inode, so if /var/spool/mail doesn't exist, and you look up
> > /var/spool/mail/hallyn, you won't get an audit record. 
> 
> 
> >  You'd have to do
> > that by auditing all open syscalls at the syscall level.
> 
> That's a wrong assumption. There is one level below the syscall level as

What is the wrong assumption?  That it has to be "at the syscall level"?
Ok, it has to be done at syscall entry or exit, if you prefer.  Using
syscall auditing, catching all fs events, and grepping with ausearch.

> well in Linux, and that is where you need to audit for this, and afaik
> audit actually does that.

Nope.

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Casey Schaufler]

--- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
 
> Ah yes.  It needed to be authoritative.  I did
> recall incorrectly.
> 
> I suspect some would argue that you are right that
> LSM is broken, but
> only because it wasn't allowed to be authoritative.

As I said at the time, I am disappointed that
authoritative hooks lost out, but it was hardly
the end of the world, and all in all, the LSM
that won out was a good first shot.

And of course, SGI's intent at the time was to
use LSM for audit. The prevailing attitude of
the day was that Linux would Never Allow Audit,
and a general scheme looked to be our best bet.
After LSM rejected authoritative hooks we
rewrote audit to use the accepted hook and,
get this, the Powers above canceled the project
the week we were to check it in.

I am happy to see the linux-audit project, and
happy to see POSIX ACLs as well. With an
authoritative LSM those would have been rolled
in and not required special interfaces of their
own. Oh well.

> Of course that
> was to increase chances of LSM upstream inclusion.

This was indeed a primary argument against
authoritative hooks, but the potential for
protrietary binary modules loomed large as
well.

> Sorry Casey and
> Linda,

Ack. That association was strictly corporate.
Please disregard.

> I bet that just makes it sting all the harder
> if LSM is now
> removed for not being sufficiently useful.

Eh, I've been right in the past and I've been
wrong in the past. I've had more code thrown out
of systems than a lot of you have ever written,
so an interface vector that's proven unpopular
isn't going to bring me down much.


Casey Schaufler
casey@schaufler-ca.com

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Olivier Galibert]

On Mon, Apr 24, 2006 at 02:54:10PM +0200, Arjan van de Ven wrote:
> 
> > While that may be true[1], it gets a little annoying when broken is
> > meant to be synonymous to "not the SELinux model".  Especially since
> > there are aspects where SELinux' security can be considered broken,
> > complexity being one of them, crappy failure modes being another,
> > handling of new files a third, handling of namespaces a fourth.
> 
> while I agree with the first three arguments, handling of namespaces
> isn't  fundamental SELinux weakness.

I'm not sure.  It's linked to the "new files" problem.
Object-labelling security (be it inodes, attributes, whatever) are
good to protect specific objects, but it sucks on two points:
- new objects can have an incorrect by-default labels
- applications don't address objects directly, but by one of their
  names, the paths

Path-based security does not protect objects, it protects what you
access through the names, whether there are associated objects or not.
So in practice path security protects the behaviour of applications
against mucking with the filesystem, while object labelling protects
the contents of the files.  They're complementary, they need each
other in practice.


> Maybe the question "is the fragility worth it" is a religious question,
> but the fundamental truth is that an inodes approach is by far more
> robust and beyond such "nothing else" statement.

It's more robust at protecting objects contents, it's less robust at
protecting application behaviour.  A lot like GR and QM, the best
model is somewhere in the middle :-)


> Now that there's a second proposed user, the real evaluation of the
> value of LSM can be made in this regard, and if the consensus is that
> it's fixable, the interfaces can be cleaned up to facilitate both
> SELinux and AppArmor. But I don't think you can a priori say that LSM is
> the right answer, given that AppArmor seems to highly struggle with it,
> nor do I think it HAS to be. I rather have separate interfaces for
> AppArmor and SELinux than one, bad, joint interface that everyone hates.

Heh, now I can agree with that.  I'm a lot more annoyed by the
arguments (not by you in particular) that go more or less:
- LSM should be removed because only SELinux uses it
- Any LSM users that is not SELinux is either broken or should be
  implemented as SELinux policies

For now if I follow correctly the LSM interfaces are decent for
object-based policy implementations, and not decent for path-based
ones.  Maybe the object-based policy hooks should be evolving in the
direction of SELinux' comfort, and additional hooks specifically for
path-based policy added, probably along the lines of what AppArmor
needs.  Then hopefully someday someone will build a security system
that uses the best features from both.  But refusing path-based policy
in the kernel for religious reasons would be annoying.

  OG.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Mon, 2006-04-24 at 16:08 +0200, Olivier Galibert wrote:
> On Mon, Apr 24, 2006 at 02:54:10PM +0200, Arjan van de Ven wrote:
> > 
> > > While that may be true[1], it gets a little annoying when broken is
> > > meant to be synonymous to "not the SELinux model".  Especially since
> > > there are aspects where SELinux' security can be considered broken,
> > > complexity being one of them, crappy failure modes being another,
> > > handling of new files a third, handling of namespaces a fourth.
> > 
> > while I agree with the first three arguments, handling of namespaces
> > isn't  fundamental SELinux weakness.
> 
> I'm not sure.  It's linked to the "new files" problem.
> Object-labelling security (be it inodes, attributes, whatever) are
> good to protect specific objects, but it sucks on two points:
> - new objects can have an incorrect by-default labels

This generally indicates a problem in policy or the application that
needs to be fixed.  It doesn't mean that object labeling is itself
problematic, anymore than the existing owner and mode information in the
inode is inherently problematic.

> - applications don't address objects directly, but by one of their
>   names, the paths
> 
> Path-based security does not protect objects, it protects what you
> access through the names, whether there are associated objects or not.
> So in practice path security protects the behaviour of applications
> against mucking with the filesystem, while object labelling protects
> the contents of the files.  They're complementary, they need each
> other in practice.

Object labeling achieves both.  It doesn't require a path-based
mechanism in the kernel.

> It's more robust at protecting objects contents, it's less robust at
> protecting application behaviour.  A lot like GR and QM, the best
> model is somewhere in the middle :-)

How is it less robust?  I haven't seen such an argument.

> For now if I follow correctly the LSM interfaces are decent for
> object-based policy implementations, and not decent for path-based
> ones.

Yes.

>   Maybe the object-based policy hooks should be evolving in the
> direction of SELinux' comfort, and additional hooks specifically for
> path-based policy added, probably along the lines of what AppArmor
> needs.  Then hopefully someday someone will build a security system
> that uses the best features from both.  But refusing path-based policy
> in the kernel for religious reasons would be annoying.

I don't think it is religious - it has to do with the kernel's internal
model and what makes sense for the kernel to implement.  And the
question is not whether policy can/should be path-based; it is whether
the kernel mechanism should be path-based.  And further, whether even
such a path-based kernel mechanism should be done in the manner in which
AppArmor does it.  Bad example, I suppose, but consider inotify - does
it regenerate pathnames in the kernel, and use those pathnames in its
own mechanism?

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Olivier Galibert]

On Tue, Apr 25, 2006 at 12:29:26PM -0400, Stephen Smalley wrote:
> On Mon, 2006-04-24 at 16:08 +0200, Olivier Galibert wrote:
> > On Mon, Apr 24, 2006 at 02:54:10PM +0200, Arjan van de Ven wrote:
> > > 
> > > > While that may be true[1], it gets a little annoying when broken is
> > > > meant to be synonymous to "not the SELinux model".  Especially since
> > > > there are aspects where SELinux' security can be considered broken,
> > > > complexity being one of them, crappy failure modes being another,
> > > > handling of new files a third, handling of namespaces a fourth.
> > > 
> > > while I agree with the first three arguments, handling of namespaces
> > > isn't  fundamental SELinux weakness.
> > 
> > I'm not sure.  It's linked to the "new files" problem.
> > Object-labelling security (be it inodes, attributes, whatever) are
> > good to protect specific objects, but it sucks on two points:
> > - new objects can have an incorrect by-default labels
> 
> This generally indicates a problem in policy or the application that
> needs to be fixed.  It doesn't mean that object labeling is itself
> problematic, anymore than the existing owner and mode information in the
> inode is inherently problematic.

Default owner and mode are handled by the kernel because otherwise it
would indeed be inherently problematic.  Don't expect normal
applications, editors or xml libraries to change from the normal
open(fname, O_RDWR|O_CREAT|O_TRUNC, 0666).  SELinux is not, and will
not, ever, be their problem.


> > - applications don't address objects directly, but by one of their
> >   names, the paths
> > 
> > Path-based security does not protect objects, it protects what you
> > access through the names, whether there are associated objects or not.
> > So in practice path security protects the behaviour of applications
> > against mucking with the filesystem, while object labelling protects
> > the contents of the files.  They're complementary, they need each
> > other in practice.
> 
> Object labeling achieves both.

In your dreams.


> I don't think it is religious - it has to do with the kernel's internal
> model and what makes sense for the kernel to implement.  And the
> question is not whether policy can/should be path-based; it is whether
> the kernel mechanism should be path-based.

"The" kernel mechanism?  The point of LSM is that there wasn't to be
one official and unique kernel mechanism.  You alternating between
"this is not acceptable because it is not SELinux" and "this is not
acceptable because it can be done with SELinux" gets a little tiring.


> And further, whether even
> such a path-based kernel mechanism should be done in the manner in which
> AppArmor does it.  Bad example, I suppose, but consider inotify - does
> it regenerate pathnames in the kernel, and use those pathnames in its
> own mechanism?

The implementation sucks, news at eleven.  At that point SELinux sucks
too, only differently, and don't even protect what is really
important[1].  Anyway, LSM is lacking path-based hooks, they should be
added in a reasonable fashion that indeed do not require regenerating
the paths or horribly slowing down hotpath code.

  OG.

[1] User data.  Because / is only a reinstall away.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Wed, 2006-04-26 at 00:26 +0200, Olivier Galibert wrote:
> On Tue, Apr 25, 2006 at 12:29:26PM -0400, Stephen Smalley wrote:
> > This generally indicates a problem in policy or the application that
> > needs to be fixed.  It doesn't mean that object labeling is itself
> > problematic, anymore than the existing owner and mode information in the
> > inode is inherently problematic.
> 
> Default owner and mode are handled by the kernel because otherwise it
> would indeed be inherently problematic.  Don't expect normal
> applications, editors or xml libraries to change from the normal
> open(fname, O_RDWR|O_CREAT|O_TRUNC, 0666).  SELinux is not, and will
> not, ever, be their problem.

First, default labeling is also handled by the kernel, as with default
owner and mode.  Files will be labeled in accordance with the policy
based on the label of the creating process, the label of a related
object (parent directory, to support inheritance properties when
appropriate), and policy rules.  But this is not always sufficient, any
more than default owner and mode is always sufficient for file creation.

Second, the entire point of SELinux is to get MAC into the mainstream,
and it is enabled by default in Fedora.  Unless that changes, it should
gradually affect a change in the applications to adapt to the presence
of SELinux, just as they have gradually adapted to other changes in the
kernel.  Such change is always painful, but MAC is necessary as a
fundamental building block if we are going to ever have improved
security.  And not all applications have to change; many can just use
the default behaviors.

> > Object labeling achieves both.
> 
> In your dreams.

Um, perhaps you could be more concrete?  Difficult to have a rational
discussion otherwise.  This division of "protecting application
behavior" vs. "protecting files" is arbitrary and meaningless.   

> > I don't think it is religious - it has to do with the kernel's internal
> > model and what makes sense for the kernel to implement.  And the
> > question is not whether policy can/should be path-based; it is whether
> > the kernel mechanism should be path-based.
> 
> "The" kernel mechanism?  The point of LSM is that there wasn't to be
> one official and unique kernel mechanism.  You alternating between
> "this is not acceptable because it is not SELinux" and "this is not
> acceptable because it can be done with SELinux" gets a little tiring.

Sorry if I wasn't clear, as that wasn't my meaning.  In my phrasing
above, "the kernel mechanism" is just referring to the kernel mechanism
of AA.  IOW, "the question is not whether AA policy can/should be
path-based; it is whether the AA kernel mechanism should be path-based".
Clearer?  Or more generally, whether a path-based mechanism belongs in
the kernel.  And this is not just limited to the security space, nor to
SELinux vs. the world.  It is a general question of what fits the
kernel's internal model and what are appropriate kernel mechanisms.  Not
my call to make, but it is reasonable for me to ask the question.  

> > And further, whether even
> > such a path-based kernel mechanism should be done in the manner in which
> > AppArmor does it.  Bad example, I suppose, but consider inotify - does
> > it regenerate pathnames in the kernel, and use those pathnames in its
> > own mechanism?
> 
> The implementation sucks, news at eleven.  At that point SELinux sucks
> too, only differently, and don't even protect what is really
> important[1].  Anyway, LSM is lacking path-based hooks, they should be
> added in a reasonable fashion that indeed do not require regenerating
> the paths or horribly slowing down hotpath code.

Actually, SELinux can protect user data, and strict policy (i.e. the
original example policy) is an example of doing that.  So don't confuse
the mechanism with specific policy configurations, please.

On the latter point, the question is whether such a mechanism is
feasible in Linux at all, and then if so, whether the AA folks are
willing to fundamentally re-architect their implementation in this
manner.  DTE was an attempt to implement implicit typing based on
pathnames in a way that did not require path regeneration.  It was
ported to LSM early on, but as I recall, the SubDomain folks were leery
of the approach.

> 
>   OG.
> 
> [1] User data.  Because / is only a reinstall away.

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Olivier Galibert]

On Wed, Apr 26, 2006 at 08:14:31AM -0400, Stephen Smalley wrote:
> On Wed, 2006-04-26 at 00:26 +0200, Olivier Galibert wrote:
> > On Tue, Apr 25, 2006 at 12:29:26PM -0400, Stephen Smalley wrote:
> > > This generally indicates a problem in policy or the application that
> > > needs to be fixed.  It doesn't mean that object labeling is itself
> > > problematic, anymore than the existing owner and mode information in the
> > > inode is inherently problematic.
> > 
> > Default owner and mode are handled by the kernel because otherwise it
> > would indeed be inherently problematic.  Don't expect normal
> > applications, editors or xml libraries to change from the normal
> > open(fname, O_RDWR|O_CREAT|O_TRUNC, 0666).  SELinux is not, and will
> > not, ever, be their problem.
> 
> First, default labeling is also handled by the kernel, as with default
> owner and mode.  Files will be labeled in accordance with the policy
> based on the label of the creating process, the label of a related
> object (parent directory, to support inheritance properties when
> appropriate), and policy rules.  But this is not always sufficient, any
> more than default owner and mode is always sufficient for file creation.

And how do you plan to get correct default label without taking
paths/names into account but only the parent directory, for these
files created by the exact same text editor:
- $HOME/.slrnrc
- $HOME/.fetchmailrc
- $HOME/.procmailrc
- $HOME/todo.txt


> Second, the entire point of SELinux is to get MAC into the mainstream,
> and it is enabled by default in Fedora.  Unless that changes, it should
> gradually affect a change in the applications to adapt to the presence
> of SELinux, just as they have gradually adapted to other changes in the
> kernel.  Such change is always painful, but MAC is necessary as a
> fundamental building block if we are going to ever have improved
> security.  And not all applications have to change; many can just use
> the default behaviors.

Something will have to tell the system that certain file names/paths
are a-priori special, whether they exist or not.  And I *mean* file
names, not objects.  And that won't happen reliably in userspace.



> Um, perhaps you could be more concrete?  Difficult to have a rational
> discussion otherwise.  This division of "protecting application
> behavior" vs. "protecting files" is arbitrary and meaningless.   

Well, take the example of .procmailrc.  It is a file that is taken
into account if it exists, but doesn't have to exist.  It is a file
which can be used to copy all the mail of one user to somewhere else,
so it is very data-security sensitive.  So this is a file that may or
may not exist, which should not be created by anybody else than the
user itself (after all, you're into protecting from root too), and
needs to be able to be created by a mac-unaware, user-preferred text
editor and just work.  How do you expect to handle that reliably
without path-based mechanisms in the kernel?

You need path-based mechanisms to at least:
- prevent/allow some specific names from being created in specific
  conditions. 

- give correct default labels to new files

Object labelling won't help here simply because all of that happens on
file creation.  And you need path-based mechanisms if you want to have
any kind of decent problem tolerance.  Because at that point, SELinux
having prevented me twice to log into my own system on the console
with two different distributions for similar causes (labels lost), I
won't trust it for any system I want to be able to access remotely
with a decent chance of success in case of problems.

  OG.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Thomas Bleher]

[-- Attachment #1: Type: text/plain, Size: 5756 bytes --]

* Olivier Galibert <galibert@pobox.com> [2006-04-26 18:03]:
> On Wed, Apr 26, 2006 at 08:14:31AM -0400, Stephen Smalley wrote:
> > On Wed, 2006-04-26 at 00:26 +0200, Olivier Galibert wrote:
> > > On Tue, Apr 25, 2006 at 12:29:26PM -0400, Stephen Smalley wrote:
> > > > This generally indicates a problem in policy or the application that
> > > > needs to be fixed.  It doesn't mean that object labeling is itself
> > > > problematic, anymore than the existing owner and mode information in the
> > > > inode is inherently problematic.
> > > 
> > > Default owner and mode are handled by the kernel because otherwise it
> > > would indeed be inherently problematic.  Don't expect normal
> > > applications, editors or xml libraries to change from the normal
> > > open(fname, O_RDWR|O_CREAT|O_TRUNC, 0666).  SELinux is not, and will
> > > not, ever, be their problem.
> > 
> > First, default labeling is also handled by the kernel, as with default
> > owner and mode.  Files will be labeled in accordance with the policy
> > based on the label of the creating process, the label of a related
> > object (parent directory, to support inheritance properties when
> > appropriate), and policy rules.  But this is not always sufficient, any
> > more than default owner and mode is always sufficient for file creation.
> 
> And how do you plan to get correct default label without taking
> paths/names into account but only the parent directory, for these
> files created by the exact same text editor:
> - $HOME/.slrnrc
> - $HOME/.fetchmailrc
> - $HOME/.procmailrc
> - $HOME/todo.txt

How do you get correct mode and ownership? The kernel doesn't handle
that either. If you need something special, you use the tools to set it
(chmod, chgrp, ...). Ditto for SELinux.
Users already have to deal with that: fetchmail will fail to run if
~/.fetchmailrc has more permissions than 0600.

SELinux can make it even easier for you if you want: 
It has a database which stores the default labels for files. You can use
"restorecon $file" to set the default label for any file. You can also
change your editor so it queries this database and sets the right label
when saving a new file.
Fedora also just added restorecond, a small daemon which uses inotify to
watch certain paths and set the right label when the file or directory
is created. Reportedly it works very well, so you can do a
	mkdir public_html; ls -lZd public_html
and already see the right label on the file.

> > Second, the entire point of SELinux is to get MAC into the mainstream,
> > and it is enabled by default in Fedora.  Unless that changes, it should
> > gradually affect a change in the applications to adapt to the presence
> > of SELinux, just as they have gradually adapted to other changes in the
> > kernel.  Such change is always painful, but MAC is necessary as a
> > fundamental building block if we are going to ever have improved
> > security.  And not all applications have to change; many can just use
> > the default behaviors.
> 
> Something will have to tell the system that certain file names/paths
> are a-priori special, whether they exist or not.  And I *mean* file
> names, not objects.  And that won't happen reliably in userspace.

Well, then I don't understand your threat model. When I move files to
another place I certainly don't want the label to change. Imagine Linux
did this on file permissions and suddenly everyone could read your
passwords out of your .fetchmailrc.old which you saved there for backup.

> > Um, perhaps you could be more concrete?  Difficult to have a rational
> > discussion otherwise.  This division of "protecting application
> > behavior" vs. "protecting files" is arbitrary and meaningless.   
> 
> Well, take the example of .procmailrc.  It is a file that is taken
> into account if it exists, but doesn't have to exist.  It is a file
> which can be used to copy all the mail of one user to somewhere else,
> so it is very data-security sensitive.  So this is a file that may or
> may not exist, which should not be created by anybody else than the
> user itself (after all, you're into protecting from root too), and
> needs to be able to be created by a mac-unaware, user-preferred text
> editor and just work.  How do you expect to handle that reliably
> without path-based mechanisms in the kernel?

Users already set modes themselves (see .fetchmailrc, .ssh,
public_html), so I don't see a problem with them calling restorecon
(see above).

> You need path-based mechanisms to at least:
> - prevent/allow some specific names from being created in specific
>   conditions. 

I don't think that fits the Unix model. If you want that you should use
separate directories.
Giving untrusted programs write access to your homedir is a bad idea,
but even if you need to do that, SELinux can protect you. In this
specific example, procmail would simply not be allowed to read files
created by untrusted programs (e.g. your IRC client).

> - give correct default labels to new files
> 
> Object labelling won't help here simply because all of that happens on
> file creation.  And you need path-based mechanisms if you want to have
> any kind of decent problem tolerance.  Because at that point, SELinux
> having prevented me twice to log into my own system on the console
> with two different distributions for similar causes (labels lost), I
> won't trust it for any system I want to be able to access remotely
> with a decent chance of success in case of problems.

Certainly there are things which could be made better - both
documentation and userspace-tools. But I don't think it requires
changing the kernel mechanism.

Thomas


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> On Llu, 2006-04-24 at 10:24 +0200, Lars Marowsky-Bree wrote:
> > On 2006-04-23T05:45:34, Valdis.Kletnieks@vt.edu wrote:
> > 
> > > > AppArmor are not likely to put careful thought into the policies that
> > > > they use?
> > > They're not likely to put careful thought into it, *AND* that saying things
> > > like "AppArmor is so *simple* to configure" only makes things worse - this
> > > encourages unqualified people to create broken policy configurations.
> > 
> > That is about the dumbest argument I've heard so far, sorry. 
> 
> Its the conclusion of most security experts I know that broken security
> is worse than no security at all. 

who is the one here showing blind faith in their security?  :)

Now don't get me wrong, I run static analysis tools against selinux
pretty regularly, and while the userspace tools get more and more scary
(as they are under development), the only thing I find in the kernel
code is the occasional unused variable.  And I'm not arguing any flaws
in the model, which indeed is more robust than the AA model.  But if
anyone is certain there are/can be no bugs in the rest of the kernel
which can circumvent selinux, or has perfect faith in their policy, then
your statement likely applies to them.

So as long as the kernel is under development, then by your logic one
might argue that using selinux, even if it is perfect in itself, is more
dangerous than using nothing.

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> On Llu, 2006-04-24 at 10:24 +0200, Lars Marowsky-Bree wrote:
> > On 2006-04-23T05:45:34, Valdis.Kletnieks@vt.edu wrote:
> > 
> > > > AppArmor are not likely to put careful thought into the policies that
> > > > they use?
> > > They're not likely to put careful thought into it, *AND* that saying things
> > > like "AppArmor is so *simple* to configure" only makes things worse - this
> > > encourages unqualified people to create broken policy configurations.
> > 
> > That is about the dumbest argument I've heard so far, sorry. 
> 
> Its the conclusion of most security experts I know that broken security
> is worse than no security at all. 

By the way, this is predicated on the assumption that the broken
security will cause the user to expose more data.  However in many cases
these days, that is sadly not the case.  Amazon will store my cc data
regardless whether they are running selinux, apparmor, or nothing.

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Alan Cox]

On Llu, 2006-04-24 at 07:56 -0500, Serge E. Hallyn wrote:
> By the way, this is predicated on the assumption that the broken
> security will cause the user to expose more data.  However in many cases
> these days, that is sadly not the case.  Amazon will store my cc data
> regardless whether they are running selinux, apparmor, or nothing.

There I disagree. They will store your CC data in a manner that is held
to be reasonable depending on the technology and risk. If "nothing" was
the security available (eg if the US had won the Bernstein case) then
you'd be phoning them to complete your order versus using https://

They are constrained by economic pressures not to screw up, strongly
amplified by the size of the class action lawsuit if their security
policy was found by most experts to be inadequate (ie negligent).

For end users the threat is probably loss of credit cards, pay pal and
other accounts for the moment, plus being used for zombie attacks. At
the moment nobody knows where the 'negligence' line is for not
maintaining your PC systems securely and as a result harming others.

The theoretical bad case is someone with more a militaristic agenda
deciding it would be fun to irrevocably lock every hard disk on every
computer in a US locale.

Thus this sort of stuff needs to be taken seriously. Can SuSE provide a
good reliable policy for AppArmour to people, can Red Hat do the same
with SELinux ?

Note I don't care about whether apparmour is integrated. If the code is
good and it can be shown it works then fine.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> Thus this sort of stuff needs to be taken seriously. Can SuSE provide a
> good reliable policy for AppArmour to people, can Red Hat do the same
> with SELinux ?

That's a little more than half the question.  The other 40% is can users
write good policies.

I think it will, and already has, become easier for selinux.  But in
this case I wonder whether some sort of contest could be beneficial.  We
all know of Russel Coker's open root selinux play machines.  That's a
powerful statement.  Things I'd like to see in addition are

	a. a similar setup with apparmour
	b. a similar setup where "mere mortals" set up the selinux policy

For the first few rounds, rather than judge one way or the other, we
could hopefully publish the results in a way to encourage a flurry of
selinux policy tools - one of which may actually be useful.

Given that AA is a 'targeted' type of setup, I guess it would need to
have a strict sshd policy, and the game would be whether the policy can
keep anyone with the root password from escaping the policy.

> Note I don't care about whether apparmour is integrated. If the code is
> good and it can be shown it works then fine.

thanks,
-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Alan Cox]

On Llu, 2006-04-24 at 09:04 -0500, Serge E. Hallyn wrote:
> Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > Thus this sort of stuff needs to be taken seriously. Can SuSE provide a
> > good reliable policy for AppArmour to people, can Red Hat do the same
> > with SELinux ?
> 
> That's a little more than half the question.  The other 40% is can users
> write good policies.

Normal users don't write file system allocation policies, they don't
configure the safety systems for their car and they don't generally
configure most other similar policies.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> On Llu, 2006-04-24 at 09:04 -0500, Serge E. Hallyn wrote:
> > Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > > Thus this sort of stuff needs to be taken seriously. Can SuSE provide a
> > > good reliable policy for AppArmour to people, can Red Hat do the same
> > > with SELinux ?
> > 
> > That's a little more than half the question.  The other 40% is can users
> > write good policies.
> 
> Normal users don't write file system allocation policies, they don't
> configure the safety systems for their car and they don't generally
> configure most other similar policies.

s/users/everyday admin/  ?

Perhaps in the end a massive amount of education is the only answer.
But in any case only good can come of such a contest.

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[David Lang]

On Mon, 24 Apr 2006, Serge E. Hallyn wrote:

> Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
>> Thus this sort of stuff needs to be taken seriously. Can SuSE provide a
>> good reliable policy for AppArmour to people, can Red Hat do the same
>> with SELinux ?
>
> That's a little more than half the question.  The other 40% is can users
> write good policies.
>
> I think it will, and already has, become easier for selinux.  But in
> this case I wonder whether some sort of contest could be beneficial.  We
> all know of Russel Coker's open root selinux play machines.  That's a
> powerful statement.  Things I'd like to see in addition are

One key difference between SELinux and AppArmor is that AA is _not_ 
designed to protect against the actions of root, it's designed to block 
attacks that would let someone become root.

becouse of this strategy it's far simpler to configure becouse you do not 
have to do all the work to control root. This also limits what it can 
defend against, and so it's not 'perfect security' (and after all there is 
only one way to get 'perfect security' 
http://www.ranum.com/security/computer_security/papers/a1-firewall/ ), but 
AA is still a useful tool.

the 'hard shell, soft center' approach isn't as secure as 'full 
hardening' (assuming that both are properly implemented), but the fact 
that it's far easier to understand and configure the hard shell means that 
it's also far more likly to be implemented properly.

remember that it's not really a matter of people deciding not to write 
SELinux policies and instead do AA, it's a matter of people deciding to 
use AA instead of doing nothing.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

> 
> the 'hard shell, soft center' approach isn't as secure as 'full 
> hardening' (assuming that both are properly implemented), but the fact 
> that it's far easier to understand and configure the hard shell means that 
> it's also far more likly to be implemented properly.

I can certainly see value in a "take away degrees of freedom" approach.
In fact many security approaches are just that, and that's just fine
with me, and clearly of value.

There is a distinction between really taking away a degree of freedom
and just appearing to do so + easy workaround. Which is why we're having
this discussion, to make sure AppArmor is of the former type ;)

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Mon, 2006-04-24 at 07:45 -0700, David Lang wrote:
> One key difference between SELinux and AppArmor is that AA is _not_ 
> designed to protect against the actions of root, it's designed to block 
> attacks that would let someone become root.

This doesn't match the documentation or implementation AFAICS.  It
specifically controls capabilities to limit root processes, and its lack
of complete mediation and use of ambiguous identifiers leaves open a
variety of paths to escalation of access.

> becouse of this strategy it's far simpler to configure becouse you do not 
> have to do all the work to control root. This also limits what it can 
> defend against, and so it's not 'perfect security' (and after all there is 
> only one way to get 'perfect security' 
> http://www.ranum.com/security/computer_security/papers/a1-firewall/ ), but 
> AA is still a useful tool.
> 
> the 'hard shell, soft center' approach isn't as secure as 'full 
> hardening' (assuming that both are properly implemented), but the fact 
> that it's far easier to understand and configure the hard shell means that 
> it's also far more likly to be implemented properly.
> 
> remember that it's not really a matter of people deciding not to write 
> SELinux policies and instead do AA, it's a matter of people deciding to 
> use AA instead of doing nothing.

Is it?  Or it a matter of people deciding to use AA and rely on it
versus e.g. using a conventional jail-style or virtualization mechanism
ala VServer or OpenVZ?

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Mon, 2006-04-24 at 09:04 -0500, Serge E. Hallyn wrote:
> Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > Thus this sort of stuff needs to be taken seriously. Can SuSE provide a
> > good reliable policy for AppArmour to people, can Red Hat do the same
> > with SELinux ?
> 
> That's a little more than half the question.  The other 40% is can users
> write good policies.
> 
> I think it will, and already has, become easier for selinux.  But in
> this case I wonder whether some sort of contest could be beneficial.  We
> all know of Russel Coker's open root selinux play machines.  That's a
> powerful statement.  Things I'd like to see in addition are
> 
> 	a. a similar setup with apparmour
> 	b. a similar setup where "mere mortals" set up the selinux policy
> 
> For the first few rounds, rather than judge one way or the other, we
> could hopefully publish the results in a way to encourage a flurry of
> selinux policy tools - one of which may actually be useful.

Personally, I view such contests or challenge machines as meaningless.
At best, they can only show the presence of a flaw, never that the
system is "secure".  And the people most capable of breaking such
systems are not likely to go near such a play machine knowingly.  The
SELinux play machines were nice from an educational point of view,
allowing people to experiment with a SELinux system without needing to
install and set it up themselves, particularly in the days when SELinux
was not integrated into any distro.  But as a meaningful measure of
security, such contests or challenge/play machines aren't really useful.

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Mon, 24 Apr 2006 10:24:24 +0200, Lars Marowsky-Bree said:
> That is about the dumbest argument I've heard so far, sorry. With the
> same argument, these people shouldn't be allowed to admin any computer
> system and be given a broom to wipe the floor, and let the experts take
> care of the world for them.

Anybody who's worked with a large community of actual end users will
agree that most of them *shouldn't* be allowed to admin their computer.

> Now that's a perfectly reasonable line of thought, and I've most
> certainly had it when it comes to HA and clusters myself, but in no
> means is it a good reasoning against the _technology_. If it is simpler
> to use, it will be simpler to use even for smart people, who can then
> put more care into their security profiles instead of worrying about the
> complexity.

I believe I stated quite clearly that there's certainly a place for tools that
allow smart people to do this work.  That's *totally* different from marketing
the tool as "So simple, a chimpanzee could do it.".

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Lars Marowsky-Bree]

On 2006-04-24T22:06:23, Valdis.Kletnieks@vt.edu wrote:

> I believe I stated quite clearly that there's certainly a place for tools that
> allow smart people to do this work.  That's *totally* different from marketing
> the tool as "So simple, a chimpanzee could do it.".

True. Yet, arguing with how a product is marketed is hardly a technical
argument relevant to the Linux kernel.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Pavel Machek]

Hi!

On Tue 18-04-06 13:13:03, Crispin Cowan wrote:
> Valdis.Kletnieks@vt.edu wrote:
> > If we heave the LSM stuff overboard, there's one thing that *will* need
> > addressing - what to do with kernel support of Posix-y capabilities.  Currently
> > some of the heavy lifting is done by security/commoncap.c.
> >
> > Frankly, that's *another* thing that we need to either *fix* so it works right,
> > or rip out of the kernel entirely.  As far as I know, there's no in-tree way
> > to make /usr/bin/ping be set-CAP_NET_RAW and have it DTRT.
> >   
> This has actually been one of the interesting developments in AppArmor.
> I also had no use for POSIX.1e capabilities; I thought they were so
> awkward as to be useless. That is, until we integrated capabilities into
> AppArmor profiles.
> 
> Consider this profile for /bin/stty
> /bin/stty {
>   #include <abstractions/base>
> 
>   capability sys_tty_config,
> 
>   /bin/stty r,
> }
> 
> This policy basically allows stty to run, read its own text file, and
> use the capability sys_tty_config. Even though it may run as root, this
> profile confines it to *only* have sys_tty_config.


What happens if I ln /bin/stty /tmp/evilstty, then exploit
vulnerability in stty? 
							Pavel
-- 
Thanks, Sharp!

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Crispin Cowan]

Pavel Machek wrote:
> On Tue 18-04-06 13:13:03, Crispin Cowan wrote:
>   
>> This has actually been one of the interesting developments in AppArmor.
>> I also had no use for POSIX.1e capabilities; I thought they were so
>> awkward as to be useless. That is, until we integrated capabilities into
>> AppArmor profiles.
>>
>> Consider this profile for /bin/stty
>> /bin/stty {
>>   #include <abstractions/base>
>>
>>   capability sys_tty_config,
>>
>>   /bin/stty r,
>> }
>>
>> This policy basically allows stty to run, read its own text file, and
>> use the capability sys_tty_config. Even though it may run as root, this
>> profile confines it to *only* have sys_tty_config.
>>     
> What happens if I ln /bin/stty /tmp/evilstty, then exploit
> vulnerability in stty? 
>   
Two things:

   1. You don't get to create such a link unless you have an unconfined
      (trusted) shell or you have a policy that says you get to create
      such a link, and
   2. You don't have permission to execute /tmp/evilstty at all, unless
      you have an unconfined (trusted) shell.

This is a really basic misunderstanding of AppArmor. All unconfined
processes are considered trusted, so attacks that suppose an unconfined
user did something very evil/stupid are not interesting. An AppArmor
policy is supposed to prevent the attacker from ever obtaining control
of an unconfined process, so just assuming that you have one doesn't
demonstrate breaking the model.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On Sat, 22 Apr 2006 20:50:15 PDT, Crispin Cowan said:
>> What happens if I ln /bin/stty /tmp/evilstty, then exploit
>> vulnerability in stty? 

A crucial point here is that the 'ln' and the actual exploit don't
have to be firmly attached to each other...

If you can get *any* unconfined user to do that 'ln' (Hmm... have you checked if
your tar/cpio/pax/etc have been patched to prohibit this when you extract an
archive?), then the exploit can be run *even in a domain that can't do the ln
that set it up*.

> This is a really basic misunderstanding of AppArmor. All unconfined
> processes are considered trusted, so attacks that suppose an unconfined
> user did something very evil/stupid are not interesting.

Unfortunately, in the *real* world, "unconfined user accidentally runs
malware that sets up the conditions for a later exploit" is an actual
real problem.  I'm sorry to see that it's just swept under the rug as
"not interesting".

Now, if you changed "not interesting" to "so damned hard we couldn't figure
out how to deal with it", I'd have a bit of sympathy for the position... ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Thomas Bleher]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

* Valdis.Kletnieks@vt.edu [2006-04-23 11:35]:
> On Sat, 22 Apr 2006 20:50:15 PDT, Crispin Cowan said:
> >> What happens if I ln /bin/stty /tmp/evilstty, then exploit
> >> vulnerability in stty? 
> 
> A crucial point here is that the 'ln' and the actual exploit don't
> have to be firmly attached to each other...

Yes, it doesn't even have to be malicious. Consider the following
example:
An admin sets up an ftp-server with write access, running as root. He
chroots it and even creates AppArmor policy for it. However, he's a bit
sloppy and configures AppArmor so that the ftpd has write access to
everything in the chroot (even the stuff in bin/). The system is still
save, however, since the ftpd can't access anything outside of his
chroot.
Later, the admin decides to save space, deletes the bin/ directory and
instead links /bin/ls into the chroot. Suddenly the system is easily
exploitable.
I think that's what people mean when they say "impossible to analyze".
You have to look at the complete filesystem state to make sure you
didn't accidently compromise the whole system.

Thomas


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Lars Marowsky-Bree]

On 2006-04-23T16:58:47, Thomas Bleher <bleher@informatik.uni-muenchen.de> wrote:

> Later, the admin decides to save space, deletes the bin/ directory and
> instead links /bin/ls into the chroot. Suddenly the system is easily
> exploitable.

Security models can be compromised by root or by dumb accomplices. Film
at eleven.

Seriously, this is not helpful. Could we instead focus on the technical
argument wrt the kernel patches?

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-24 at 10:28 +0200, Lars Marowsky-Bree wrote:
> On 2006-04-23T16:58:47, Thomas Bleher <bleher@informatik.uni-muenchen.de> wrote:
> 
> > Later, the admin decides to save space, deletes the bin/ directory and
> > instead links /bin/ls into the chroot. Suddenly the system is easily
> > exploitable.
> 
> Security models can be compromised by root or by dumb accomplices. Film
> at eleven.

well this security model wants to partition root, more or less. So to
some degree looking at it makes sense; just not so much in the given
example ;)


> Seriously, this is not helpful. Could we instead focus on the
> technical argument wrt the kernel patches?

I disagree with your stance here; trying to poke holes in the mechanism
IS useful and important. In addition to looking at the kernel patches. 
I understand your employer wants this merged asap, but that's no reason
to try to stop discussions that try to poke holes in the security model.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Lars Marowsky-Bree]

On 2006-04-24T10:37:17, Arjan van de Ven <arjan@infradead.org> wrote:

> > Security models can be compromised by root or by dumb accomplices. Film
> > at eleven.
> well this security model wants to partition root, more or less. So to
> some degree looking at it makes sense; just not so much in the given
> example ;)

True.

> > Seriously, this is not helpful. Could we instead focus on the
> > technical argument wrt the kernel patches?
> I disagree with your stance here; trying to poke holes in the
> mechanism IS useful and important. In addition to looking at the
> kernel patches. 

I agree, sort-of. Yet, I'd argue that the holes tried to poke here rely
on the admin being sloppish not with regular operation, but _while
configuring the security policy_. The only way to protect against that
is to shoot the admin on sight.

Which might not be a bad idea, looking at the stats of the human error
still being the most dangerous detail in any equation, yet it may be
considered impractical.

> I understand your employer wants this merged asap, but that's no reason
> to try to stop discussions that try to poke holes in the security model.

I resent that remark. At the same level I could argue that some other
people in this discussion do have a professional interest in getting it
_not_ merged. (And LSM ripped out _now_ before it gets a chance to
address the comments made so far.) I'd rather not go there. 

But while we're there, just really briefly, it is important to point out
that while Novell/SUSE obviously _does_ have a corporate interest, it is
not required for this to be "ASAP", and I trust that Crispin, Tony et
al will work to incorporate all feedback received. I don't think we're
in any rush, and even if LSM _is_ ripped out, that just means that the
patch series will be augmented with a further patch [01/xx] "Reinstate
LSM hooks w/additional provisions to address code cleanliness."

Going back to the technical side of things, I'd be more happy if the
holes poked were something you could reasonably expect to be able to
protect against.


Sincerely,
    Lars Marowsky-Brée

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-24 at 10:54 +0200, Lars Marowsky-Bree wrote:
> > > Seriously, this is not helpful. Could we instead focus on the
> > > technical argument wrt the kernel patches?
> > I disagree with your stance here; trying to poke holes in the
> > mechanism IS useful and important. In addition to looking at the
> > kernel patches. 
> 
> I agree, sort-of. Yet, I'd argue that the holes tried to poke here rely
> on the admin being sloppish not with regular operation, but _while
> configuring the security policy_. The only way to protect against that
> is to shoot the admin on sight.

yet exploring this space is worthwhile to a certain degree to find the
edges and see if there's a valid issue. Killing the discussion
prematurely makes no sense (but giving too much value to it doesn't make
too much sense either)

> al will work to incorporate all feedback received. I don't think we're
> in any rush, and even if LSM _is_ ripped out, that just means that the
> patch series will be augmented with a further patch [01/xx] "Reinstate
> LSM hooks w/additional provisions to address code cleanliness."

Now that the second user is laid bare, I do think it's a valid thing to
at least reevaluate the current state of LSM. So far it appears to not
really be the right interface for AppArmor, and it's also not really the
right interface for SELinux. And it has downsides in its design (the
function pointer tree is just a major source for sucky performance;
processors regardless of vendor don't like function pointer calls much).

So at minimum a debate about most the hooks is in order, as well as the
mechanism; I'm increasingly getting convinced the 'security_ops' thing
is misdesigned. I rather have a setup where the hooks at compiletime
resolve to the function of the LSM you've chosen (be it SELinux or
AppArmor) rather than the current solution. It's not like you
realistically can or want to provide both SELinux and AppArmor with the
same kernel anyway.. 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Mon, 24 Apr 2006 11:12:22 +0200, Arjan van de Ven said:

> So at minimum a debate about most the hooks is in order, as well as the
> mechanism; I'm increasingly getting convinced the 'security_ops' thing
> is misdesigned. I rather have a setup where the hooks at compiletime
> resolve to the function of the LSM you've chosen (be it SELinux or
> AppArmor) rather than the current solution. It's not like you
> realistically can or want to provide both SELinux and AppArmor with the
> same kernel anyway.. 

Doing so would require some redesign work for the current code that uses
the pointers to stack SELinux and capabilities.  Not a show-stopper by
any means, just an entry for the 'to-do' list if we go that route...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Pavel Machek]

Hi!

> If we heave the LSM stuff overboard, there's one thing that *will* need
> addressing - what to do with kernel support of Posix-y capabilities.  Currently
> some of the heavy lifting is done by security/commoncap.c.
> 
> Frankly, that's *another* thing that we need to either *fix* so it works right,
> or rip out of the kernel entirely.  As far as I know, there's no in-tree way
> to make /usr/bin/ping be set-CAP_NET_RAW and have it DTRT.

Well, you can still have ping drop all but CAP_NET_RAW as a first
thing in main(), which is almost as good. And IIRC some apps actually
do that...

-- 
Thanks, Sharp!

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Mon, 17 Apr 2006 22:26:24 BST, Alan Cox said:

> You can implement a BSD securelevel model in SELinux as far as I can see
> from looking at it, and do it better than the code today, so its not
> really a feature drop anyway just a migration away from some fossils

For a while, I had some LSM code that implemented a large chunk of the
OpenWall/PAX restrictions.  But it never stacked well with SELinux, and in
time the SELinux code got more expressive and allowed doing almost everything
that the OpenWall stuff did.

The best case I can make for it today is "somebody might want to harden the
box a little bit, but not have the resources (mostly liveware) to do SELinux".
On the other hand, that also can be read as "Cargo-cult security is better
than no security at all".

If somebody wants to carry that banner, they're welcome to it.  At this point,
I'd be willing to heave most of the LSM framework over the side as long as we
keep the right to add a new SELinux hook if we can defend its existence (see
the recent additions to allow SELinux mediation of network stuff as an example).

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Jan Engelhardt]

>> > Seriously that makes a lot of sense.  All other modules people have come up
>> > with over the last years are irrelevant and/or broken by design.
>> 
>> It's been nearly a year since I proposed this, and we've not seen any 
>> appropriate LSM modules submitted in that time.
>> 
>> See
>> http://thread.gmane.org/gmane.linux.kernel.lsm/1120
>> http://thread.gmane.org/gmane.linux.kernel.lsm/1088
>> 
>> The only reason I can see to not delete it immediately is to give BSD 
>> secure levels users a heads-up, although I thought it was already slated 
>> for removal.  BSD secure levels is fundamentally broken and should 
>> never have gone into mainline.
>
>been a very long time and so far, only out-of-tree LSMs are present,
>with no public statements about getting them submitted into the main
>kernel tree.  And, I think almost all of the out-of-tree modules already
>need other kernel patches to get their code working properly, so what's
>a few more hooks needed...
>
>/me pokes the bushes to flush out the people lurking
>

Well then, have a look at http://alphagate.hopto.org/multiadm/

There is a reason to why people [read: I] do not submit out-of-tree (OOT)
modules; because I think chances are low that they get in. Sad fact about the
Linux kernel.

>Oh, but do remember, the main goal of LSM was to stop people from
>arguing about different security models.  Now that it is in, we haven't
>had any bickering about different types of things that should go into
>mainline, all with different models and usages.  Everyone gets to play
>in their own sandbox and not worry about anyone else.  If the LSM
>interface was to go away, that problem would start happening again, and
>I don't think we want to go there.
>
>So, I think the only way to be able to realisticly keep the LSM
>interface, is for a valid, working, maintained LSM-based security model
>to go into the kernel tree.  So far, I haven't seen any public posting
>of patches that meet this requirement :(

In that case, maybe it would be worthwhile to flip the positions, i.e. LSM on
top of SELinux, sort of a compat layer.



Jan Engelhardt
-- 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Greg KH]

On Wed, Apr 19, 2006 at 10:16:46AM +0200, Jan Engelhardt wrote:
> >> > Seriously that makes a lot of sense.  All other modules people have come up
> >> > with over the last years are irrelevant and/or broken by design.
> >> 
> >> It's been nearly a year since I proposed this, and we've not seen any 
> >> appropriate LSM modules submitted in that time.
> >> 
> >> See
> >> http://thread.gmane.org/gmane.linux.kernel.lsm/1120
> >> http://thread.gmane.org/gmane.linux.kernel.lsm/1088
> >> 
> >> The only reason I can see to not delete it immediately is to give BSD 
> >> secure levels users a heads-up, although I thought it was already slated 
> >> for removal.  BSD secure levels is fundamentally broken and should 
> >> never have gone into mainline.
> >
> >been a very long time and so far, only out-of-tree LSMs are present,
> >with no public statements about getting them submitted into the main
> >kernel tree.  And, I think almost all of the out-of-tree modules already
> >need other kernel patches to get their code working properly, so what's
> >a few more hooks needed...
> >
> >/me pokes the bushes to flush out the people lurking
> >
> 
> Well then, have a look at http://alphagate.hopto.org/multiadm/
> 
> There is a reason to why people [read: I] do not submit out-of-tree (OOT)
> modules; because I think chances are low that they get in. Sad fact about the
> Linux kernel.

Why do you feel this way.  We document how to get patches applied very
well (look in Documentation/SubmittingPatches and Documentation/HOWTO),
and provide good review comments on anything that is posted.

We also have a kernel-mentors mailing list that people use to vet their
patches to get them into shape for submission.

So please feel free to submit your patch, especially as without another
LSM user in the kernel tree, the interface will probably go away.

thanks,

greg k-h

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[James Morris]

On Wed, 19 Apr 2006, Greg KH wrote:

> So please feel free to submit your patch, especially as without another
> LSM user in the kernel tree, the interface will probably go away.

At this point, LSM has really proven itself to be a bad interface and 
should probably go away in any case.

Its semantics are too weak, and developers are not designing their code 
according to what is suitable for the kernel, but rather, whatever happens 
to fit easily into LSM, which us just about anything.

The LSM interface is also being abused by several proprietary kernel 
modules, some of which are not even security related.  In one case, 
there's code which dangerously revectors SELinux with a shim layer 
designed to try and bypass the GPL.  Some of this is a response to 
unexporting the syscall table, where projects which abused that have now 
switched to LSM.

I think it's clear now, if it wasn't already, that bad interfaces foster 
bad code.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Greg KH]

On Wed, Apr 19, 2006 at 12:33:24PM -0400, James Morris wrote:
> The LSM interface is also being abused by several proprietary kernel 
> modules, some of which are not even security related.  In one case, 
> there's code which dangerously revectors SELinux with a shim layer 
> designed to try and bypass the GPL.  Some of this is a response to 
> unexporting the syscall table, where projects which abused that have now 
> switched to LSM.

I agree that this is happening today.  Which makes me wonder, why is the
variable "security_ops" exported through "EXPORT_SYMBOL()" and not
"EXPORT_SYMBOL_GPL()"?  It seems that people are taking advantage of
this and changing it would help slow them down a bit.

Chris, would you take a patch to change this?

thanks,

greg k-h

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Chris Wright]

* Greg KH (greg@kroah.com) wrote:
> On Wed, Apr 19, 2006 at 12:33:24PM -0400, James Morris wrote:
> > The LSM interface is also being abused by several proprietary kernel 
> > modules, some of which are not even security related.  In one case, 
> > there's code which dangerously revectors SELinux with a shim layer 
> > designed to try and bypass the GPL.  Some of this is a response to 
> > unexporting the syscall table, where projects which abused that have now 
> > switched to LSM.
> 
> I agree that this is happening today.  Which makes me wonder, why is the
> variable "security_ops" exported through "EXPORT_SYMBOL()" and not
> "EXPORT_SYMBOL_GPL()"?  It seems that people are taking advantage of
> this and changing it would help slow them down a bit.
> 
> Chris, would you take a patch to change this?

I don't see any reason not to.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Wed, 2006-04-19 at 11:10 -0700, Greg KH wrote:
> On Wed, Apr 19, 2006 at 12:33:24PM -0400, James Morris wrote:
> > The LSM interface is also being abused by several proprietary kernel 
> > modules, some of which are not even security related.  In one case, 
> > there's code which dangerously revectors SELinux with a shim layer 
> > designed to try and bypass the GPL.  Some of this is a response to 
> > unexporting the syscall table, where projects which abused that have now 
> > switched to LSM.
> 
> I agree that this is happening today.  Which makes me wonder, why is the
> variable "security_ops" exported through "EXPORT_SYMBOL()" and not
> "EXPORT_SYMBOL_GPL()"?  It seems that people are taking advantage of
> this and changing it would help slow them down a bit.
> 
> Chris, would you take a patch to change this?

Seems like a rather weak mechanism.   Compared to eliminating
security_ops altogether.

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Wed, 2006-04-19 at 11:10 -0700, Greg KH wrote:
> > On Wed, Apr 19, 2006 at 12:33:24PM -0400, James Morris wrote:
> > > The LSM interface is also being abused by several proprietary kernel 
> > > modules, some of which are not even security related.  In one case, 
> > > there's code which dangerously revectors SELinux with a shim layer 
> > > designed to try and bypass the GPL.  Some of this is a response to 
> > > unexporting the syscall table, where projects which abused that have now 
> > > switched to LSM.
> > 
> > I agree that this is happening today.  Which makes me wonder, why is the
> > variable "security_ops" exported through "EXPORT_SYMBOL()" and not
> > "EXPORT_SYMBOL_GPL()"?  It seems that people are taking advantage of
> > this and changing it would help slow them down a bit.
> > 
> > Chris, would you take a patch to change this?
> 
> Seems like a rather weak mechanism.   Compared to eliminating
> security_ops altogether.

Yup, that'll achieve the goal as well  :-)

-serge

Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Greg KH]

On Thu, Apr 20, 2006 at 08:39:51AM -0400, Stephen Smalley wrote:
> On Wed, 2006-04-19 at 11:10 -0700, Greg KH wrote:
> > On Wed, Apr 19, 2006 at 12:33:24PM -0400, James Morris wrote:
> > > The LSM interface is also being abused by several proprietary kernel 
> > > modules, some of which are not even security related.  In one case, 
> > > there's code which dangerously revectors SELinux with a shim layer 
> > > designed to try and bypass the GPL.  Some of this is a response to 
> > > unexporting the syscall table, where projects which abused that have now 
> > > switched to LSM.
> > 
> > I agree that this is happening today.  Which makes me wonder, why is the
> > variable "security_ops" exported through "EXPORT_SYMBOL()" and not
> > "EXPORT_SYMBOL_GPL()"?  It seems that people are taking advantage of
> > this and changing it would help slow them down a bit.
> > 
> > Chris, would you take a patch to change this?
> 
> Seems like a rather weak mechanism.   Compared to eliminating
> security_ops altogether.

I agree.  In looking over the code some more, I'm trying to figure out
why we are exporting that variable at all.  Is it because of people
wanting to stack security modules?

I see selinux code using it, but you are always built into the kernel,
right?  So unexporting it would not be an issue to you.

Tony, would AppArmor have problems if we don't export that variable
anymore?

thanks,

greg k-h

Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Stephen Smalley]

On Thu, 2006-04-20 at 08:00 -0700, Greg KH wrote:
> I agree.  In looking over the code some more, I'm trying to figure out
> why we are exporting that variable at all.  Is it because of people
> wanting to stack security modules?
> 
> I see selinux code using it, but you are always built into the kernel,
> right?  So unexporting it would not be an issue to you.

Various in-tree modules (e.g. ext3) call security hooks via the static
inlines and end up referencing security_ops directly.  We'd have to wrap
all such hooks in the same manner as capable and permission.

Although I was actually talking about eliminating security_ops, not just
un-exporting it ;)

> Tony, would AppArmor have problems if we don't export that variable
> anymore?

-- 
Stephen Smalley
National Security Agency

Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Greg KH]

On Thu, Apr 20, 2006 at 10:20:11AM -0400, Stephen Smalley wrote:
> On Thu, 2006-04-20 at 08:00 -0700, Greg KH wrote:
> > I agree.  In looking over the code some more, I'm trying to figure out
> > why we are exporting that variable at all.  Is it because of people
> > wanting to stack security modules?
> > 
> > I see selinux code using it, but you are always built into the kernel,
> > right?  So unexporting it would not be an issue to you.
> 
> Various in-tree modules (e.g. ext3) call security hooks via the static
> inlines and end up referencing security_ops directly.  We'd have to wrap
> all such hooks in the same manner as capable and permission.

Ah, and people like making their file systems as modules :(

> Although I was actually talking about eliminating security_ops, not just
> un-exporting it ;)

Yes, that would be even better, and solve some of the recent complaints
that people have with the lsm interface.

thanks,

greg k-h

Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Christoph Hellwig]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1055 bytes --]

On Thu, Apr 20, 2006 at 09:15:52AM -0700, Greg KH wrote:
> On Thu, Apr 20, 2006 at 10:20:11AM -0400, Stephen Smalley wrote:
> > On Thu, 2006-04-20 at 08:00 -0700, Greg KH wrote:
> > > I agree.  In looking over the code some more, I'm trying to figure out
> > > why we are exporting that variable at all.  Is it because of people
> > > wanting to stack security modules?
> > > 
> > > I see selinux code using it, but you are always built into the kernel,
> > > right?  So unexporting it would not be an issue to you.
> > 
> > Various in-tree modules (e.g. ext3) call security hooks via the static
> > inlines and end up referencing security_ops directly.  We'd have to wrap
> > all such hooks in the same manner as capable and permission.
> 
> Ah, and people like making their file systems as modules :(

But actually yes, calling into rændom lsm hooks in modules is not a good
thing.a  The only think filesystems calls is security_inode_init_security
and it would make a lot of sense to make that an out of line wrapper
instead of exporting security_ops.

Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Stephen Smalley]

On Thu, 2006-04-20 at 17:23 +0100, Christoph Hellwig wrote:
> On Thu, Apr 20, 2006 at 09:15:52AM -0700, Greg KH wrote:
> > On Thu, Apr 20, 2006 at 10:20:11AM -0400, Stephen Smalley wrote:
> > > On Thu, 2006-04-20 at 08:00 -0700, Greg KH wrote:
> > > > I agree.  In looking over the code some more, I'm trying to figure out
> > > > why we are exporting that variable at all.  Is it because of people
> > > > wanting to stack security modules?
> > > > 
> > > > I see selinux code using it, but you are always built into the kernel,
> > > > right?  So unexporting it would not be an issue to you.
> > > 
> > > Various in-tree modules (e.g. ext3) call security hooks via the static
> > > inlines and end up referencing security_ops directly.  We'd have to wrap
> > > all such hooks in the same manner as capable and permission.
> > 
> > Ah, and people like making their file systems as modules :(
> 
> But actually yes, calling into rndom lsm hooks in modules is not a good
> thing.a  The only think filesystems calls is security_inode_init_security
> and it would make a lot of sense to make that an out of line wrapper
> instead of exporting security_ops.

There are other cases as well, I think, e.g. af_unix calls certain hooks
to ensure mediation of even the abstract namespace.  But the problem is
avoided altogether if the security static inlines compile down to direct
selinux function calls (which can be exported as needed).

-- 
Stephen Smalley
National Security Agency

Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Greg KH]

On Thu, Apr 20, 2006 at 12:34:57PM -0400, Stephen Smalley wrote:
> On Thu, 2006-04-20 at 17:23 +0100, Christoph Hellwig wrote:
> > On Thu, Apr 20, 2006 at 09:15:52AM -0700, Greg KH wrote:
> > > On Thu, Apr 20, 2006 at 10:20:11AM -0400, Stephen Smalley wrote:
> > > > On Thu, 2006-04-20 at 08:00 -0700, Greg KH wrote:
> > > > > I agree.  In looking over the code some more, I'm trying to figure out
> > > > > why we are exporting that variable at all.  Is it because of people
> > > > > wanting to stack security modules?
> > > > > 
> > > > > I see selinux code using it, but you are always built into the kernel,
> > > > > right?  So unexporting it would not be an issue to you.
> > > > 
> > > > Various in-tree modules (e.g. ext3) call security hooks via the static
> > > > inlines and end up referencing security_ops directly.  We'd have to wrap
> > > > all such hooks in the same manner as capable and permission.
> > > 
> > > Ah, and people like making their file systems as modules :(
> > 
> > But actually yes, calling into rndom lsm hooks in modules is not a good
> > thing.a  The only think filesystems calls is security_inode_init_security
> > and it would make a lot of sense to make that an out of line wrapper
> > instead of exporting security_ops.
> 
> There are other cases as well, I think, e.g. af_unix calls certain hooks
> to ensure mediation of even the abstract namespace.  But the problem is
> avoided altogether if the security static inlines compile down to direct
> selinux function calls (which can be exported as needed).

Of course it's "avoided alltogether" but we are not talking about
dropping the whole LSM interface here right now.  I am wanting something
that can go into 2.6.17 to fix this issue this week.

thanks,

greg k-h

Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Stephen Smalley]

On Thu, 2006-04-20 at 09:46 -0700, Greg KH wrote:
> On Thu, Apr 20, 2006 at 12:34:57PM -0400, Stephen Smalley wrote:
> > On Thu, 2006-04-20 at 17:23 +0100, Christoph Hellwig wrote:
> > > On Thu, Apr 20, 2006 at 09:15:52AM -0700, Greg KH wrote:
> > > > On Thu, Apr 20, 2006 at 10:20:11AM -0400, Stephen Smalley wrote:
> > > > > On Thu, 2006-04-20 at 08:00 -0700, Greg KH wrote:
> > > > > > I agree.  In looking over the code some more, I'm trying to figure out
> > > > > > why we are exporting that variable at all.  Is it because of people
> > > > > > wanting to stack security modules?
> > > > > > 
> > > > > > I see selinux code using it, but you are always built into the kernel,
> > > > > > right?  So unexporting it would not be an issue to you.
> > > > > 
> > > > > Various in-tree modules (e.g. ext3) call security hooks via the static
> > > > > inlines and end up referencing security_ops directly.  We'd have to wrap
> > > > > all such hooks in the same manner as capable and permission.
> > > > 
> > > > Ah, and people like making their file systems as modules :(
> > > 
> > > But actually yes, calling into rndom lsm hooks in modules is not a good
> > > thing.a  The only think filesystems calls is security_inode_init_security
> > > and it would make a lot of sense to make that an out of line wrapper
> > > instead of exporting security_ops.
> > 
> > There are other cases as well, I think, e.g. af_unix calls certain hooks
> > to ensure mediation of even the abstract namespace.  But the problem is
> > avoided altogether if the security static inlines compile down to direct
> > selinux function calls (which can be exported as needed).
> 
> Of course it's "avoided alltogether" but we are not talking about
> dropping the whole LSM interface here right now.  I am wanting something
> that can go into 2.6.17 to fix this issue this week.

Ah, I see - didn't realize you were targeting 2.6.17 for this change.
In that case, your original proposal of just making it _GPL makes the
most sense for 2.6.17, and then look to introduce out of line wrappers
for all affected hooks (or remove LSM, if that is decided) later.

-- 
Stephen Smalley
National Security Agency

[PATCH] make security_ops EXPORT_SYMBOL_GPL()

[Greg KH]

Some closed source modules are taking advantage of the fact that the
security_ops variable is available to them, so they are using it to hook
into parts of the kernel that should only be available to "real" users
of the LSM interface (which is required to be under the GPL.)

This patch changes the export of that variable to try to mitigate the
problem.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 security/security.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- gregkh-2.6.orig/security/security.c
+++ gregkh-2.6/security/security.c
@@ -178,4 +178,4 @@ EXPORT_SYMBOL_GPL(register_security);
 EXPORT_SYMBOL_GPL(unregister_security);
 EXPORT_SYMBOL_GPL(mod_reg_security);
 EXPORT_SYMBOL_GPL(mod_unreg_security);
-EXPORT_SYMBOL(security_ops);
+EXPORT_SYMBOL_GPL(security_ops);

Re: [PATCH] make security_ops EXPORT_SYMBOL_GPL()

[Linus Torvalds]

On Thu, 20 Apr 2006, Greg KH wrote:
>
> Some closed source modules are taking advantage of the fact that the
> security_ops variable is available to them, so they are using it to hook
> into parts of the kernel that should only be available to "real" users
> of the LSM interface (which is required to be under the GPL.)

I'm really not going to apply this.

It's insane. 

"security_ops" is used by _anything_ that uses the inline functions in 
<linux/security.h>, which suddenly means that a non-GPL module cannot use 
_any_ of the standard security tests. That's insane.

And there's no point to this patch. The "explanation" I have seen so far 
is that some strange root-kit could take over the security ops. That's 
just crazy talk. If you're a root-kit, would you care about the copyright 
license? No. So this patch just makes zero sense from any standpoint.

If people want to remove security_ops, that's fine (not for 2.6.17, but 
assuming you guys can come to some reasonable agreement, at some later 
date). But turning it into a GPL-only, but leaving all the infrastructure 
requiring it is not.

		Linus

Re: [PATCH] make security_ops EXPORT_SYMBOL_GPL()

[Greg KH]

On Thu, Apr 20, 2006 at 11:08:23AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 20 Apr 2006, Greg KH wrote:
> >
> > Some closed source modules are taking advantage of the fact that the
> > security_ops variable is available to them, so they are using it to hook
> > into parts of the kernel that should only be available to "real" users
> > of the LSM interface (which is required to be under the GPL.)
> 
> I'm really not going to apply this.
> 
> It's insane. 
> 
> "security_ops" is used by _anything_ that uses the inline functions in 
> <linux/security.h>, which suddenly means that a non-GPL module cannot use 
> _any_ of the standard security tests. That's insane.

Ah, doh, you are right, sorry about that.

> If people want to remove security_ops, that's fine (not for 2.6.17, but 
> assuming you guys can come to some reasonable agreement, at some later 
> date). But turning it into a GPL-only, but leaving all the infrastructure 
> requiring it is not.

Fair enough, I'll work toward removing security_ops so that it is no
longer needed at all.

thanks,

greg k-h

Re: [PATCH] make security_ops EXPORT_SYMBOL_GPL()

[Greg KH]

On Thu, Apr 20, 2006 at 12:34:23PM -0700, Greg KH wrote:
> On Thu, Apr 20, 2006 at 11:08:23AM -0700, Linus Torvalds wrote:
> > If people want to remove security_ops, that's fine (not for 2.6.17, but 
> > assuming you guys can come to some reasonable agreement, at some later 
> > date). But turning it into a GPL-only, but leaving all the infrastructure 
> > requiring it is not.
> 
> Fair enough, I'll work toward removing security_ops so that it is no
> longer needed at all.

Ok, that was pretty foolish of me to attempt.  We could move all of the
inline functions in security.h to a .c file for when the LSM framework
is enabled, but that might cause some slowdowns.  Although I remember
that Kurt Garloff did some work in this area in the past, showing that
moving these out of inline caused some improvements on ia64.

Anyway, for now I'm not going to worry about this, it isn't that
important...

Sorry for the noise.

greg k-h

Re: [PATCH] make security_ops EXPORT_SYMBOL_GPL()

[Chris Wright]

* Greg KH (greg@kroah.com) wrote:
> On Thu, Apr 20, 2006 at 12:34:23PM -0700, Greg KH wrote:
> > On Thu, Apr 20, 2006 at 11:08:23AM -0700, Linus Torvalds wrote:
> > > If people want to remove security_ops, that's fine (not for 2.6.17, but 
> > > assuming you guys can come to some reasonable agreement, at some later 
> > > date). But turning it into a GPL-only, but leaving all the infrastructure 
> > > requiring it is not.
> > 
> > Fair enough, I'll work toward removing security_ops so that it is no
> > longer needed at all.
> 
> Ok, that was pretty foolish of me to attempt.  We could move all of the
> inline functions in security.h to a .c file for when the LSM framework
> is enabled, but that might cause some slowdowns.  Although I remember
> that Kurt Garloff did some work in this area in the past, showing that
> moving these out of inline caused some improvements on ia64.

No, those patches didn't deinline anything.  Rather eliminated the
indirect call via sercurity_ops when possible.  I was actually in the
process of ressurecting those when this whole thread broke out.

> Anyway, for now I'm not going to worry about this, it isn't that
> important...

Agreed ;-)

thanks,
-chris

Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Tony Jones]

On Thu, Apr 20, 2006 at 08:00:37AM -0700, Greg KH wrote:

> Tony, would AppArmor have problems if we don't export that variable
> anymore?

I don't believe so. We are just a user of register_security and we don't
poke around the exported symbol. I guess I'll defer full judgement till I
see the actual patch but based on the 10,000' it seems reasonable to me.

Anyways, it seems like for the immediate you're just looking at tagging
it EXPORT_SYMBOL_GPL which sounds fine too.  I need to make you a t-shirt
with that on it :)

Tony

Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM)

[Chris Wright]

(sorry if this is repeat, my mail server is dying, and mail is coming in
seriously out of order)

* Greg KH (greg@kroah.com) wrote:
> I agree.  In looking over the code some more, I'm trying to figure out
> why we are exporting that variable at all.  Is it because of people
> wanting to stack security modules?

No, the issue is simple.  There's a all the static inlines which use
security_ops, and some of them are placed in modular code.

thanks,
-chris

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Jan Engelhardt]

>> 
>> Well then, have a look at http://alphagate.hopto.org/multiadm/
>> 
>> There is a reason to why people [read: I] do not submit out-of-tree
>> (OOT) modules; because I think chances are low that they get in. Sad
>> fact about the Linux kernel.
>
>Why do you feel this way.  We document how to get patches applied very
>well (look in Documentation/SubmittingPatches and
>Documentation/HOWTO), and provide good review comments on anything
>that is posted.
>

In case of MultiAdm: It adds some more LSM hooks, some of which have
received a frown.[1] And it adds a ton of changes scattered throughout
the kernel (namely replacing capable() with capable_x()) -- I would
suppose these would be ignored to death even more than [1]. Just look
at the 2.6.15-mtadm.diff within the multiadm package.

In general: I am probably too strongly tied to my own CodingStyle to
change it for Documentation/CodingStyle. (Regarding tabs-vs-space. I'm
flexible about indent level.) After all, I have to maintain it... If
someone else makes the necessary adjustments, let it be.

>We also have a kernel-mentors mailing list that people use to vet
>their patches to get them into shape for submission.
>
>So please feel free to submit your patch, especially as without
>another LSM user in the kernel tree, the interface will probably go
>away.


[1] http://tinyurl.com/opo8h
    (long url below, should the tinyurl go away someday)



Jan Engelhardt
-- 
[1] http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/ef106f193befdbe5/79896dc45b0d5944?lnk=st&q=security_task_post_setgid+author%3AJan+author%3AEngelhardt&rnum=1&hl=en#79896dc45b0d5944

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Greg KH]

On Wed, Apr 19, 2006 at 09:22:07PM +0200, Jan Engelhardt wrote:
> In general: I am probably too strongly tied to my own CodingStyle to
> change it for Documentation/CodingStyle.

There's a very good reason the kernel has a consistant coding style, so
if you don't want to adapt to it, do not expect to ever get your code
accepted, it's that simple.

Sorry to hear that such a trivial thing is going to trip you up.

greg k-h

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Serge E. Hallyn]

Quoting Greg KH (greg@kroah.com):
> On Wed, Apr 19, 2006 at 09:22:07PM +0200, Jan Engelhardt wrote:
> > In general: I am probably too strongly tied to my own CodingStyle to
> > change it for Documentation/CodingStyle.
> 
> There's a very good reason the kernel has a consistant coding style, so
> if you don't want to adapt to it, do not expect to ever get your code
> accepted, it's that simple.
> 
> Sorry to hear that such a trivial thing is going to trip you up.

Greg,

I think what really tripped him up was the response to his attempt
to get the new hooks introduced:  tinyurl.com/opo8h

Jan,

I think that the last response, by Chrisw, in that thread, was not
a snide comment, but a legitimate request for a justification for
the hooks.  If they are a crucial part of your module, then i assume
they should be pretty easy for you to defend, right?

I think it would be worth trying again.

-serge

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Randy.Dunlap]

On Wed, 19 Apr 2006 13:48:24 -0700 Greg KH wrote:

> On Wed, Apr 19, 2006 at 09:22:07PM +0200, Jan Engelhardt wrote:
> > In general: I am probably too strongly tied to my own CodingStyle to
> > change it for Documentation/CodingStyle.
> 
> There's a very good reason the kernel has a consistant coding style, so
> if you don't want to adapt to it, do not expect to ever get your code
> accepted, it's that simple.
> 
> Sorry to hear that such a trivial thing is going to trip you up.

I agree.  It sounded like an excuse to me, not a justifiable
reason.

---
~Randy

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Wed, 2006-04-19 at 10:16 +0200, Jan Engelhardt wrote:
> 
> Well then, have a look at http://alphagate.hopto.org/multiadm/
> 

hmm on first sight that seems to be basically an extension to the
existing capability() code... rather than a 'real' LSM module. Am I
missing something here?

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Jan Engelhardt]

>> 
>> Well then, have a look at http://alphagate.hopto.org/multiadm/
>> 
>
>hmm on first sight that seems to be basically an extension to the
>existing capability() code... rather than a 'real' LSM module. Am I
>missing something here?
>

(So what's the definition for a "real" LSM module?)

It's quite a "big" extension to the capability code inasfar as that 
access is not solely granted based on capabilities, but a matrix of 
capabilities plus UID/GID of filesystem objects.

This is not a "for fun" LSM like rootplug, but it was specifically 
developed to address some permission issues in an educational institution. 
The LSM hooks were there (and some more are added with MultiAdm), and it 
seemed a lot simpler than setting up SELinux.


Jan Engelhardt
-- 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Greg KH]

On Wed, Apr 19, 2006 at 09:06:57PM +0200, Jan Engelhardt wrote:
> >> 
> >> Well then, have a look at http://alphagate.hopto.org/multiadm/
> >> 
> >
> >hmm on first sight that seems to be basically an extension to the
> >existing capability() code... rather than a 'real' LSM module. Am I
> >missing something here?
> >
> 
> (So what's the definition for a "real" LSM module?)

No idea, try submitting the patch :)

thanks,

greg k-h

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Randy.Dunlap]

On Wed, 19 Apr 2006 13:11:54 -0700 Greg KH wrote:

> On Wed, Apr 19, 2006 at 09:06:57PM +0200, Jan Engelhardt wrote:
> > >> 
> > >> Well then, have a look at http://alphagate.hopto.org/multiadm/
> > >> 
> > >
> > >hmm on first sight that seems to be basically an extension to the
> > >existing capability() code... rather than a 'real' LSM module. Am I
> > >missing something here?
> > >
> > 
> > (So what's the definition for a "real" LSM module?)
> 
> No idea, try submitting the patch :)

hrm, I guess the smiley is supposed to help??

surely someone knows that it takes to qualify as a "real"
LSM module.  I would have expected Greg to be in that group
of people.

---
~Randy

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Wed, 2006-04-19 at 13:52 -0700, Randy.Dunlap wrote:
> On Wed, 19 Apr 2006 13:11:54 -0700 Greg KH wrote:
> 
> > On Wed, Apr 19, 2006 at 09:06:57PM +0200, Jan Engelhardt wrote:
> > > >> 
> > > >> Well then, have a look at http://alphagate.hopto.org/multiadm/
> > > >> 
> > > >
> > > >hmm on first sight that seems to be basically an extension to the
> > > >existing capability() code... rather than a 'real' LSM module. Am I
> > > >missing something here?
> > > >
> > > 
> > > (So what's the definition for a "real" LSM module?)
> > 
> > No idea, try submitting the patch :)
> 
> hrm, I guess the smiley is supposed to help??
> 
> surely someone knows that it takes to qualify as a "real"
> LSM module.  

ok for me it would be "implements it's own security_ops vector" as
criterium. 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Jan Engelhardt]

>
>ok for me it would be "implements it's own security_ops vector" as
>criterium. 
>
multiadm does that. :>



Jan Engelhardt
-- 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Wed, 2006-04-19 at 13:52 -0700, Randy.Dunlap wrote:
> On Wed, 19 Apr 2006 13:11:54 -0700 Greg KH wrote:
> 
> > On Wed, Apr 19, 2006 at 09:06:57PM +0200, Jan Engelhardt wrote:
> > > >> 
> > > >> Well then, have a look at http://alphagate.hopto.org/multiadm/
> > > >> 
> > > >
> > > >hmm on first sight that seems to be basically an extension to the
> > > >existing capability() code... rather than a 'real' LSM module. Am I
> > > >missing something here?
> > > >
> > > 
> > > (So what's the definition for a "real" LSM module?)
> > 
> > No idea, try submitting the patch :)
> 
> hrm, I guess the smiley is supposed to help??
> 
> surely someone knows that it takes to qualify as a "real"
> LSM module.  I would have expected Greg to be in that group
> of people.

Herein lies the basic problem with LSM - it is not a well-defined
framework in any sense.  Versus say the Flask architecture within
SELinux, which establishes a framework with well-defined semantics that
can support a wide range of security models, but not arbitrary ones.

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Jan Engelhardt]

>> >> Well then, have a look at http://alphagate.hopto.org/multiadm/
>> >
>> >hmm on first sight that seems to be basically an extension to the
>> >existing capability() code... rather than a 'real' LSM module. Am I
>> >missing something here?
>> 
>> (So what's the definition for a "real" LSM module?)
>
>No idea, try submitting the patch :)
>
Because it's too big, you only get URLs:

[01/02] http://alphagate.hopto.org/multiadm/mtadm_hooks-2.6.17-rc2.diff  137KB
[02/02] http://alphagate.hopto.org/multiadm/mtadm_module-2.6.17-rc2.diff  27KB

Don't mention CodingStyle, I know. This is just a post to respond to the
topic on why noone submitted it earlier.
I already see it coming...


Jan Engelhardt
-- 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Greg KH]

On Fri, Apr 21, 2006 at 03:30:26PM +0200, Jan Engelhardt wrote:
> >> >> Well then, have a look at http://alphagate.hopto.org/multiadm/
> >> >
> >> >hmm on first sight that seems to be basically an extension to the
> >> >existing capability() code... rather than a 'real' LSM module. Am I
> >> >missing something here?
> >> 
> >> (So what's the definition for a "real" LSM module?)
> >
> >No idea, try submitting the patch :)
> >
> Because it's too big, you only get URLs:
> 
> [01/02] http://alphagate.hopto.org/multiadm/mtadm_hooks-2.6.17-rc2.diff  137KB
> [02/02] http://alphagate.hopto.org/multiadm/mtadm_module-2.6.17-rc2.diff  27KB
> 
> Don't mention CodingStyle, I know. This is just a post to respond to the
> topic on why noone submitted it earlier.
> I already see it coming...

I don't understand.  Do you really want to get this module into the
kernel?  Or are you just posting it here for the link when people
stumble across it in the archives?

thanks,

greg k-h

[PATCH 0/4] MultiAdmin LSM

[Jan Engelhardt]

Subject: [PATCH 0/4] MultiAdmin LSM
         (was: Re: Time to remove LSM
         (was: Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks))


0. Preface
==========
Thanks to Greg who, requiring me to post more-split patches, made me
reconsider the code. I did nothing less than to simplified the whole patch
cruft (shrunk by factor 10) and removed what seemed unreasonable. This
thread posts MultiAdmin *1.0.5*.



1. Super-short description
==========================
Three user classes exist (determined by user-defined UID ranges),
    - superadmin, the usual "root"
    - subadmin
    - normal users

A usual (non-multiadm,non-selinux) system has only one superadmin (UID 0)
and a number of normal users, and the superadmin can operate on
everything.

The "subadmin" can read in some superadmin-only places, and is allowed to
fully operate on processes/files/ipc/etc. of normal users. The full list
(possibly incomplete) of permissions is available in the README.txt
(includes short description) in the out-of-tree tarball.
[http://freshmeat.net/p/multiadm/]



2. A small problem
==================
As cool as it may sound, I think the implementation is not as clean as
possible.

Let's pick a random starting point: The subadmin is allowed to call
drivers/char/lp.c:lp_ioctl():LPGETSTATS. Or
fs/quota.c:generic_quotactl_valid():Q_GET*/Q_XGET*. For that to work
without too much code changes, CAP_SYS_ADMIN must be given to the
subadmin.

However, CAP_SYS_ADMIN (others are affected too, but this is the main one)
is used for other things too (mostly write or ioctl operations), which is
actually something that should not be granted to the subadmin.

This poses a problem. Currently, it is solved by adding an extra LSM hook,
security_cap_extra(), called from capable(). The hooked function then
looks at current->*uid/*gid and returns 1 or 0, depending on whether an
action is allowed or not. For more details see patch #1.



3. Conclusion
=============
You might have noticed: MultiAdmin's concept is based on UIDs/GIDs, not
capabilities. This interferes with the capability framework, which is
currently... hardcoded.

At best I would want that capabilities get out of the core functions (e.g.
{kernel,fs,etc}/*.c) and have them get their place in security/*, so that
in case you load a security module that is not based around POSIX
capabilities, they don't get used. I will see if I can put this idea into
a working idea. But for now...

...the multiadm patch series, based upon giving CAP_almost_anything
to subadmin and 'reducing' permissions within the LSM.



4. Patches
==========
Compile-tested (defconfig + enabling SECURIY,SECURITY_NETWORK).
A small overview for pleasure:

[01] security_cap_extra() and more
[02] Use of capable_light()
[03] task_post_setgid()
[04] MultiAdmin module


Jan Engelhardt
-- 

[PATCH 1/4] security_cap_extra() and more

[Jan Engelhardt]

[PATCH 1/4] security_cap_extra() and more

    -   Renames capable() to capable_light().
        This function is used if only a capability is to be checked.

    -   Implement a new capable that calls security_cap_extra().
        Since a subadmin has almost the same capabilities as a
        superadmin, an extra helper is needed to decide whether an
        action is allowed, based on the philosophy of the LSM.

    -   implement the .cap_extra LSM hook


Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/include/linux/capability.h linux-2.6.17-rc3+/include/linux/capability.h
--- linux-2.6.17-rc3~/include/linux/capability.h	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/include/linux/capability.h	2006-04-30 23:25:25.233048000 +0200
@@ -357,6 +357,8 @@ static inline kernel_cap_t cap_invert(ke
 
 #define cap_is_fs_cap(c)     (CAP_TO_MASK(c) & CAP_FS_MASK)
 
+int capable_light(int);
+int __capable_light(struct task_struct *, int);
 int capable(int cap);
 int __capable(struct task_struct *t, int cap);
 
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/include/linux/security.h linux-2.6.17-rc3+/include/linux/security.h
--- linux-2.6.17-rc3~/include/linux/security.h	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/include/linux/security.h	2006-04-30 23:25:35.893048000 +0200
@@ -1319,6 +1319,7 @@ struct security_operations {
 
 #endif	/* CONFIG_KEYS */
 
+	int (*cap_extra)(int);
 };
 
 /* global variables */
@@ -2018,6 +2019,11 @@ static inline int security_netlink_recv(
 	return security_ops->netlink_recv(skb);
 }
 
+static inline int security_cap_extra(int cap)
+{
+	return security_ops->cap_extra(cap);
+}
+
 /* prototypes */
 extern int security_init	(void);
 extern int register_security	(struct security_operations *ops);
@@ -2651,6 +2657,12 @@ static inline int security_netlink_recv 
 	return cap_netlink_recv (skb);
 }
 
+static inline int security_cap_extra(int cap);
+{
+	/* Capability test already passed. No more checks. => Allow. */
+	return 1;
+}
+
 static inline struct dentry *securityfs_create_dir(const char *name,
 					struct dentry *parent)
 {
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/kernel/capability.c linux-2.6.17-rc3+/kernel/capability.c
--- linux-2.6.17-rc3~/kernel/capability.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/kernel/capability.c	2006-04-30 23:30:06.143048000 +0200
@@ -238,7 +238,7 @@ int __capable(struct task_struct *t, int
 {
 	if (security_capable(t, cap) == 0) {
 		t->flags |= PF_SUPERPRIV;
-		return 1;
+		return security_cap_extra(cap);
 	}
 	return 0;
 }
@@ -249,3 +249,20 @@ int capable(int cap)
 	return __capable(current, cap);
 }
 EXPORT_SYMBOL(capable);
+
+int __capable_light(struct task_struct *t, int cap)
+{
+	if (security_capable(t, cap) == 0) {
+		t->flags |= PF_SUPERPRIV;
+		return 1;
+	}
+	return 0;
+}
+EXPORT_SYMBOL(__capable_light);
+
+int capable_light(int cap)
+{
+	return __capable_light(current, cap);
+}
+EXPORT_SYMBOL(capable_light);
+
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/dummy.c linux-2.6.17-rc3+/security/dummy.c
--- linux-2.6.17-rc3~/security/dummy.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/security/dummy.c	2006-04-30 23:30:24.763048000 +0200
@@ -677,6 +677,11 @@ static int dummy_netlink_recv (struct sk
 	return 0;
 }
 
+static int dummy_cap_extra(int cap)
+{
+	return 1; /* allow */
+}
+
 #ifdef CONFIG_SECURITY_NETWORK
 static int dummy_unix_stream_connect (struct socket *sock,
 				      struct socket *other,
@@ -1040,5 +1045,6 @@ void security_fixup_ops (struct security
 	set_to_dummy_if_null(ops, key_permission);
 #endif	/* CONFIG_KEYS */
 
+	set_to_dummy_if_null(ops, cap_extra);
 }
 
#<<eof>>


Jan Engelhardt
-- 

[PATCH 2/4] Use of capable_light()

[Jan Engelhardt]

[PATCH 2/4] Use of capable_light()

capable() now behaves like (capable_light() && is_superadm). Since some
operations are allowed by subadmins too, it suffices to use
capable_light().


Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/arch/alpha/kernel/pci-noop.c linux-2.6.17-rc3+/arch/alpha/kernel/pci-noop.c
--- linux-2.6.17-rc3~/arch/alpha/kernel/pci-noop.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/arch/alpha/kernel/pci-noop.c	2006-04-30 22:05:33.263048000 +0200
@@ -89,7 +89,7 @@ asmlinkage long
 sys_pciconfig_read(unsigned long bus, unsigned long dfn,
 		   unsigned long off, unsigned long len, void *buf)
 {
-	if (!capable(CAP_SYS_ADMIN))
+	if (!capable_light(CAP_SYS_ADMIN))
 		return -EPERM;
 	else
 		return -ENODEV;
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/drivers/char/lp.c linux-2.6.17-rc3+/drivers/char/lp.c
--- linux-2.6.17-rc3~/drivers/char/lp.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/drivers/char/lp.c	2006-04-30 22:28:53.433048000 +0200
@@ -633,7 +633,7 @@ static int lp_ioctl(struct inode *inode,
 			if (copy_to_user(argp, &LP_STAT(minor),
 					sizeof(struct lp_stats)))
 				return -EFAULT;
-			if (capable(CAP_SYS_ADMIN))
+			if (capable_light(CAP_SYS_ADMIN))
 				memset(&LP_STAT(minor), 0,
 						sizeof(struct lp_stats));
 			break;
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/drivers/firmware/efivars.c linux-2.6.17-rc3+/drivers/firmware/efivars.c
--- linux-2.6.17-rc3~/drivers/firmware/efivars.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/drivers/firmware/efivars.c	2006-04-30 22:29:38.913048000 +0200
@@ -354,7 +354,7 @@ static ssize_t efivar_attr_show(struct k
 	struct efivar_attribute *efivar_attr = to_efivar_attr(attr);
 	ssize_t ret = -EIO;
 
-	if (!capable(CAP_SYS_ADMIN))
+	if (!capable_light(CAP_SYS_ADMIN))
 		return -EACCES;
 
 	if (efivar_attr->show) {
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/drivers/pci/pci-sysfs.c linux-2.6.17-rc3+/drivers/pci/pci-sysfs.c
--- linux-2.6.17-rc3~/drivers/pci/pci-sysfs.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/drivers/pci/pci-sysfs.c	2006-04-30 22:31:33.873048000 +0200
@@ -113,7 +113,7 @@ pci_read_config(struct kobject *kobj, ch
 	u8 *data = (u8*) buf;
 
 	/* Several chips lock up trying to read undefined config space */
-	if (capable(CAP_SYS_ADMIN)) {
+	if (capable_light(CAP_SYS_ADMIN)) {
 		size = dev->cfg_size;
 	} else if (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
 		size = 128;
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/drivers/pci/proc.c linux-2.6.17-rc3+/drivers/pci/proc.c
--- linux-2.6.17-rc3~/drivers/pci/proc.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/drivers/pci/proc.c	2006-04-30 22:31:42.213048000 +0200
@@ -60,7 +60,7 @@ proc_bus_pci_read(struct file *file, cha
 	 * undefined locations (think of Intel PIIX4 as a typical example).
 	 */
 
-	if (capable(CAP_SYS_ADMIN))
+	if (capable_light(CAP_SYS_ADMIN))
 		size = dev->cfg_size;
 	else if (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
 		size = 128;
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/drivers/pci/syscall.c linux-2.6.17-rc3+/drivers/pci/syscall.c
--- linux-2.6.17-rc3~/drivers/pci/syscall.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/drivers/pci/syscall.c	2006-04-30 22:31:51.863048000 +0200
@@ -27,7 +27,7 @@ sys_pciconfig_read(unsigned long bus, un
 	long err, cfg_ret;
 
 	err = -EPERM;
-	if (!capable(CAP_SYS_ADMIN))
+	if (!capable_light(CAP_SYS_ADMIN))
 		goto error;
 
 	err = -ENODEV;
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/fs/quota.c linux-2.6.17-rc3+/fs/quota.c
--- linux-2.6.17-rc3~/fs/quota.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/fs/quota.c	2006-04-30 22:40:03.483048000 +0200
@@ -81,11 +81,11 @@ static int generic_quotactl_valid(struct
 	if (cmd == Q_GETQUOTA) {
 		if (((type == USRQUOTA && current->euid != id) ||
 		     (type == GRPQUOTA && !in_egroup_p(id))) &&
-		    !capable(CAP_SYS_ADMIN))
+		    !capable_light(CAP_SYS_ADMIN))
 			return -EPERM;
 	}
 	else if (cmd != Q_GETFMT && cmd != Q_SYNC && cmd != Q_GETINFO)
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable_light(CAP_SYS_ADMIN))
 			return -EPERM;
 
 	return 0;
@@ -132,10 +132,10 @@ static int xqm_quotactl_valid(struct sup
 	if (cmd == Q_XGETQUOTA) {
 		if (((type == XQM_USRQUOTA && current->euid != id) ||
 		     (type == XQM_GRPQUOTA && !in_egroup_p(id))) &&
-		     !capable(CAP_SYS_ADMIN))
+		     !capable_light(CAP_SYS_ADMIN))
 			return -EPERM;
 	} else if (cmd != Q_XGETQSTAT && cmd != Q_XQUOTASYNC) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable_light(CAP_SYS_ADMIN))
 			return -EPERM;
 	}
 
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/ipc/msg.c linux-2.6.17-rc3+/ipc/msg.c
--- linux-2.6.17-rc3~/ipc/msg.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/ipc/msg.c	2006-04-30 22:52:53.383048000 +0200
@@ -449,7 +449,7 @@ asmlinkage long sys_msgctl (int msqid, i
 	ipcp = &msq->q_perm;
 	err = -EPERM;
 	if (current->euid != ipcp->cuid && 
-	    current->euid != ipcp->uid && !capable(CAP_SYS_ADMIN))
+	    current->euid != ipcp->uid && !capable_light(CAP_SYS_ADMIN))
 	    /* We _could_ check for CAP_CHOWN above, but we don't */
 		goto out_unlock_up;
 
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/ipc/sem.c linux-2.6.17-rc3+/ipc/sem.c
--- linux-2.6.17-rc3~/ipc/sem.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/ipc/sem.c	2006-04-30 22:54:15.703048000 +0200
@@ -821,7 +821,7 @@ static int semctl_down(int semid, int se
 	}	
 	ipcp = &sma->sem_perm;
 	if (current->euid != ipcp->cuid && 
-	    current->euid != ipcp->uid && !capable(CAP_SYS_ADMIN)) {
+	    current->euid != ipcp->uid && !capable_light(CAP_SYS_ADMIN)) {
 	    	err=-EPERM;
 		goto out_unlock;
 	}
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/ipc/shm.c linux-2.6.17-rc3+/ipc/shm.c
--- linux-2.6.17-rc3~/ipc/shm.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/ipc/shm.c	2006-04-30 22:55:10.413048000 +0200
@@ -596,7 +596,7 @@ asmlinkage long sys_shmctl (int shmid, i
 
 		if (current->euid != shp->shm_perm.uid &&
 		    current->euid != shp->shm_perm.cuid && 
-		    !capable(CAP_SYS_ADMIN)) {
+		    !capable_light(CAP_SYS_ADMIN)) {
 			err=-EPERM;
 			goto out_unlock_up;
 		}
@@ -636,7 +636,7 @@ asmlinkage long sys_shmctl (int shmid, i
 		err=-EPERM;
 		if (current->euid != shp->shm_perm.uid &&
 		    current->euid != shp->shm_perm.cuid && 
-		    !capable(CAP_SYS_ADMIN)) {
+		    !capable_light(CAP_SYS_ADMIN)) {
 			goto out_unlock_up;
 		}
 
#<<eof>>


Jan Engelhardt
-- 

[PATCH 3/4] task_post_setgid()

[Jan Engelhardt]

[PATCH 3/4] task_post_setgid()

    -   Implement the task_post_setgid() LSM hook which is required by
        MultiAdmin to switch between classes.
        (task_post_setuid also switches between classes -- and already exists)


Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/include/linux/security.h linux-2.6.17-rc3+/include/linux/security.h
--- linux-2.6.17-rc3~/include/linux/security.h	2006-05-01 09:57:13.112832000 +0200
+++ linux-2.6.17-rc3+/include/linux/security.h	2006-05-01 09:57:38.182832000 +0200
@@ -1320,6 +1320,7 @@ struct security_operations {
 #endif	/* CONFIG_KEYS */
 
 	int (*cap_extra)(int);
+	int (*task_post_setgid)(gid_t, gid_t, gid_t, int);
 };
 
 /* global variables */
@@ -2024,6 +2025,11 @@ static inline int security_cap_extra(int
 	return security_ops->cap_extra(cap);
 }
 
+static inline int security_task_post_setgid(gid_t r, gid_t e, gid_t s, int t)
+{
+	return security_ops->task_post_setgid(r, e, s, t);
+}
+
 /* prototypes */
 extern int security_init	(void);
 extern int register_security	(struct security_operations *ops);
@@ -2663,6 +2669,11 @@ static inline int security_cap_extra(int
 	return 1;
 }
 
+static inline int security_task_post_setgid(gid_t r, gid_t e, gid_t s, int t)
+{
+	return 0;
+}
+
 static inline struct dentry *securityfs_create_dir(const char *name,
 					struct dentry *parent)
 {
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/kernel/sys.c linux-2.6.17-rc3+/kernel/sys.c
--- linux-2.6.17-rc3~/kernel/sys.c	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/kernel/sys.c	2006-05-01 09:57:38.192832000 +0200
@@ -836,7 +836,7 @@ asmlinkage long sys_setregid(gid_t rgid,
 	current->gid = new_rgid;
 	key_fsgid_changed(current);
 	proc_id_connector(current, PROC_EVENT_GID);
-	return 0;
+	return security_task_post_setgid(old_rgid, old_egid, (gid_t)-1, LSM_SETID_RE);
 }
 
 /*
@@ -846,6 +846,7 @@ asmlinkage long sys_setregid(gid_t rgid,
  */
 asmlinkage long sys_setgid(gid_t gid)
 {
+	gid_t old_rgid = current->gid;
 	int old_egid = current->egid;
 	int retval;
 
@@ -876,7 +877,7 @@ asmlinkage long sys_setgid(gid_t gid)
 
 	key_fsgid_changed(current);
 	proc_id_connector(current, PROC_EVENT_GID);
-	return 0;
+	return security_task_post_setgid(old_rgid, (gid_t)-1, (gid_t)-1, LSM_SETID_ID);
 }
   
 static int set_user(uid_t new_ruid, int dumpclear)
@@ -1083,6 +1084,8 @@ asmlinkage long sys_getresuid(uid_t __us
  */
 asmlinkage long sys_setresgid(gid_t rgid, gid_t egid, gid_t sgid)
 {
+	gid_t old_rgid = current->gid, old_egid = current->egid,
+	      old_sgid = current->sgid;
 	int retval;
 
 	retval = security_task_setgid(rgid, egid, sgid, LSM_SETID_RES);
@@ -1116,7 +1119,7 @@ asmlinkage long sys_setresgid(gid_t rgid
 
 	key_fsgid_changed(current);
 	proc_id_connector(current, PROC_EVENT_GID);
-	return 0;
+	return security_task_post_setgid(old_rgid, old_egid, old_sgid, LSM_SETID_RES);
 }
 
 asmlinkage long sys_getresgid(gid_t __user *rgid, gid_t __user *egid, gid_t __user *sgid)
@@ -1189,6 +1192,7 @@ asmlinkage long sys_setfsgid(gid_t gid)
 		key_fsgid_changed(current);
 		proc_id_connector(current, PROC_EVENT_GID);
 	}
+	security_task_post_setgid(old_fsgid, (gid_t)-1, (gid_t)-1, LSM_SETID_FS);
 	return old_fsgid;
 }
 
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/dummy.c linux-2.6.17-rc3+/security/dummy.c
--- linux-2.6.17-rc3~/security/dummy.c	2006-05-01 09:57:13.112832000 +0200
+++ linux-2.6.17-rc3+/security/dummy.c	2006-05-01 09:57:38.192832000 +0200
@@ -682,6 +682,11 @@ static int dummy_cap_extra(int cap)
 	return 1; /* allow */
 }
 
+static int dummy_task_post_setgid(gid_t r, gid_t e, gid_t s, int t)
+{
+	return 0;
+}
+
 #ifdef CONFIG_SECURITY_NETWORK
 static int dummy_unix_stream_connect (struct socket *sock,
 				      struct socket *other,
@@ -1046,5 +1051,6 @@ void security_fixup_ops (struct security
 #endif	/* CONFIG_KEYS */
 
 	set_to_dummy_if_null(ops, cap_extra);
+	set_to_dummy_if_null(ops, task_post_setgid);
 }
 
#<<eof>>


Jan Engelhardt
-- 

[PATCH 4/4] MultiAdmin module

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 26337 bytes --]


[PATCH 4/4] MultiAdmin module

    -   Add the MultiAdmin to the mainline tree.
        I hope the rest is self-explanatory.

Please do not mention CodingStyle for multiadm.c. I already know it. :)
And I will get to it should it really be merged.


Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/Kconfig linux-2.6.17-rc3+/security/Kconfig
--- linux-2.6.17-rc3~/security/Kconfig	2006-05-01 12:47:01.382832000 +0200
+++ linux-2.6.17-rc3+/security/Kconfig	2006-05-01 15:04:08.482832000 +0200
@@ -99,6 +99,22 @@ config SECURITY_SECLVL
 
 	  If you are unsure how to answer this question, answer N.
 
+config SECURITY_MULTIADM
+    tristate "MultiAdmin secuirty module"
+    depends on SECURITY
+    ---help---
+        The MultiAdmin security kernel module provides means to have multiple
+        "root" users with unique UIDs. This fixes collation order problems
+        which for example appear with NSCD, allows to have files with
+        determinable owner and allows to track the quota usage for every
+        user, since they now have a unique uid.
+        
+        It also implements a "sub-admin", a partially restricted root user
+        (or enhanced normal user, depending on the way you see it), who has
+        full read-only access to most subsystems, and additional write rights
+        only to a limited subset, e.g. writing to files or killing processes
+        only of certain users.
+
 source security/selinux/Kconfig
 
 endmenu
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/Makefile linux-2.6.17-rc3+/security/Makefile
--- linux-2.6.17-rc3~/security/Makefile	2006-05-01 12:47:01.382832000 +0200
+++ linux-2.6.17-rc3+/security/Makefile	2006-05-01 15:04:08.482832000 +0200
@@ -17,3 +17,4 @@ obj-$(CONFIG_SECURITY_SELINUX)		+= selin
 obj-$(CONFIG_SECURITY_CAPABILITIES)	+= commoncap.o capability.o
 obj-$(CONFIG_SECURITY_ROOTPLUG)		+= commoncap.o root_plug.o
 obj-$(CONFIG_SECURITY_SECLVL)		+= seclvl.o
+obj-$(CONFIG_SECURITY_MULTIADM)		+= commoncap.o multiadm.o
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/loadme linux-2.6.17-rc3+/security/loadme
--- linux-2.6.17-rc3~/security/loadme	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.17-rc3+/security/loadme	2006-05-01 15:16:27.662832000 +0200
@@ -0,0 +1,6 @@
+#!/bin/bash
+
+rmmod multiadm;
+modprobe commoncap;
+insmod ./multiadm.ko Supergid=0 Subuid_start=4000 \
+	Subuid_end=4000 Wrtuid_start=4003 Wrtuid_end=4004;
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/multiadm.c linux-2.6.17-rc3+/security/multiadm.c
--- linux-2.6.17-rc3~/security/multiadm.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.17-rc3+/security/multiadm.c	2006-05-01 15:39:13.042832000 +0200
@@ -0,0 +1,618 @@
+/*=============================================================================
+| MultiAdmin Security Module                                                  |
+| Copyright © Jan Engelhardt <jengelh [at] gmx de>, 2005 - 2006               |
+| v1.0.5, May 2006                                                            |
+| http://alphagate.hopto.org/                                                 |
+`-----------------------------------------------------------------------------'
+
+    This program is free software; you can redistribute it and/or
+    modify it under the terms of the GNU General Public License
+    version 2 as published by the Free Software Foundation.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+    General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program kit; if not, write to:
+    Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
+    Boston, MA  02110-1301  USA
+=============================================================================*/
+#include <asm/siginfo.h>
+#include <linux/binfmts.h>
+#include <linux/capability.h>
+#include <linux/config.h>
+#include <linux/dcache.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/ipc.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/namei.h>
+#include <linux/sched.h>
+#include <linux/securebits.h>
+#include <linux/security.h>
+#include <linux/sem.h>
+#include <linux/types.h>
+
+#if !defined(CONFIG_SECURITY_CAPABILITIES) && \
+    !defined(CONFIG_SECURITY_CAPABILITIES_MODULE)
+#        error You need to have CONFIG_SECURITY_CAPABILITIES=y or =m \
+               for MultiAdmin to compile successfully.
+#endif
+
+#define BASENAME "multiadm"
+#define PREFIX BASENAME ": "
+
+/*
+This typedef is used to mark functions a littile without interfering
+with the ABI:
+    bool for  0=failure, !0=success
+    int  for  0=success, <0=failure, >0=failure or some val
+    int  for  0=eof,     <0=failure, >0=value
+*/
+typedef int bool;
+
+static int mt_bprm_set_security(struct linux_binprm *);
+static int mt_cap_extra(int);
+static int mt_inode_permission(struct inode *, int, struct nameidata *);
+static int mt_inode_setattr(struct dentry *, struct iattr *);
+static int mt_ipc_permission(struct kern_ipc_perm *, short);
+static int mt_msq_msgctl(struct msg_queue *, int);
+static int mt_ptrace(task_t *, task_t *);
+static int mt_quotactl(int, int, int, struct super_block *);
+static int mt_sem_semctl(struct sem_array *, int);
+static int mt_shm_shmctl(struct shmid_kernel *, int);
+static int mt_task_kill(task_t *, struct siginfo *, int);
+static int mt_task_post_setuid(uid_t, uid_t, uid_t, int);
+static int mt_task_post_setgid(gid_t, gid_t, gid_t, int);
+static int mt_task_setnice(task_t *, int);
+static int mt_task_setscheduler(task_t *, int, struct sched_param *);
+static int mt_task_setuid(uid_t, uid_t, uid_t, int);
+
+static inline void chg2_superadm(kernel_cap_t *);
+static inline void chg2_subadm(kernel_cap_t *);
+static inline void chg2_netadm(kernel_cap_t *);
+static inline bool is_any_superadm(uid_t, gid_t);
+static inline bool is_uid_superadm(uid_t);
+static inline bool is_gid_superadm(gid_t);
+static inline bool is_any_subadm(uid_t, gid_t);
+static inline bool is_uid_subadm(uid_t);
+static inline bool is_gid_subadm(gid_t);
+static inline bool is_uid_netadm(uid_t);
+static inline bool is_uid_user(uid_t);
+static inline bool is_task1_user(const task_t *);
+static inline bool is_task_user(const task_t *);
+static inline bool range_intersect(uid_t, uid_t, uid_t, uid_t);
+static inline bool range_intersect_wrt(uid_t, uid_t, uid_t, uid_t);
+
+static struct security_operations mt_secops = {
+    .bprm_apply_creds      = cap_bprm_apply_creds,
+    .bprm_set_security     = mt_bprm_set_security,
+    .cap_extra             = mt_cap_extra,
+    .capable               = cap_capable,
+    .capget                = cap_capget,
+    .capset_check          = cap_capset_check,
+    .capset_set            = cap_capset_set,
+    .inode_permission      = mt_inode_permission,
+    .inode_setattr         = mt_inode_setattr,
+    .ipc_permission        = mt_ipc_permission,
+    .msg_queue_msgctl      = mt_msq_msgctl,
+    .ptrace                = mt_ptrace,
+    .quotactl              = mt_quotactl,
+    .sem_semctl            = mt_sem_semctl,
+    .shm_shmctl            = mt_shm_shmctl,
+    .task_kill             = mt_task_kill,
+    .task_post_setuid      = mt_task_post_setuid,
+    .task_post_setgid      = mt_task_post_setgid,
+    .task_setnice          = mt_task_setnice,
+    .task_setscheduler     = mt_task_setscheduler,
+    .task_setuid           = mt_task_setuid,
+};
+static gid_t Supergid = -1, Subgid = -1;
+static uid_t Superuid_start = 0,  Superuid_end = 0,
+             Subuid_start   = -1, Subuid_end   = -1,
+             Netuid         = -1,
+             Wrtuid_start   = -1, Wrtuid_end   = -1;
+static int Secondary = 0;
+
+MODULE_DESCRIPTION("MultiAdmin Security Module; http://alphagate.hopto.org/");
+MODULE_AUTHOR("Jan Engelhardt <jengelh [at] gmx de>");
+MODULE_LICENSE("GPL");
+module_param(Supergid,       int, S_IRUSR | S_IWUSR);
+module_param(Superuid_start, int, S_IRUSR | S_IWUSR);
+module_param(Superuid_end,   int, S_IRUSR | S_IWUSR);
+module_param(Subuid_start,   int, S_IRUSR | S_IWUSR);
+module_param(Subuid_end,     int, S_IRUSR | S_IWUSR);
+module_param(Subgid,         int, S_IRUSR | S_IWUSR);
+module_param(Netuid,         int, S_IRUSR | S_IWUSR);
+module_param(Wrtuid_start,   int, S_IRUGO | S_IWUSR);
+module_param(Wrtuid_end,     int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(Wrtuid_start,   "First UID of the write-enabled user range");
+MODULE_PARM_DESC(Wrtuid_end,     "Last UID of the write-enabled user range");
+MODULE_PARM_DESC(Superuid_start, "First UIDs of the superadmin range");
+MODULE_PARM_DESC(Superuid_end,   "Last UID of the superadmin range");
+MODULE_PARM_DESC(Supergid,       "Superadmin GID");
+MODULE_PARM_DESC(Subuid_start,   "First UIDs of the subadmin range");
+MODULE_PARM_DESC(Subuid_end,     "Last UID of the subadmin range");
+MODULE_PARM_DESC(Subgid,         "Subadmin GID");
+MODULE_PARM_DESC(Netuid,         "Netadmin UID");
+
+//-----------------------------------------------------------------------------
+__init static int multiadm_init(void) {
+    int eax = 0, ebx = 0;
+    if((eax = register_security(&mt_secops)) != 0) {
+        if((ebx = mod_reg_security(BASENAME, &mt_secops)) != 0) {
+            printk(KERN_WARNING PREFIX
+            "Could not register with kernel: %d, %d\n", eax, ebx);
+            return ebx;
+        }
+        Secondary = 1;
+    }
+
+    if(range_intersect(Superuid_start, Superuid_end, Subuid_start, Subuid_end))
+        printk(KERN_WARNING PREFIX
+          "Superadmin and Subadmin ranges intersect! Unpredictable behavior"
+          " may result: some operations may classify you as a superadmin,"
+          " others as a subadmin. Security leak: subadmin could possibly"
+          " change into superadmin!\n"
+        );
+    if(range_intersect(Superuid_start, Superuid_end, Netuid, Netuid))
+        printk(KERN_WARNING PREFIX "Netuid within superadmin range! -Has more "
+               "powers than intended!\n");
+    if(range_intersect(Superuid_start, Superuid_end, Wrtuid_start, Wrtuid_end))
+        printk(KERN_WARNING PREFIX "Superadmin and write-enabled user range "
+               "intersect! A subadmin could setuid() into a superadmin!\n");
+    if(range_intersect(Subuid_start, Subuid_end, Netuid, Netuid))
+        printk(KERN_WARNING PREFIX "Netuid within subadmin range! -Has more "
+               "powers than intended!\n");
+    if(range_intersect_wrt(Subuid_start, Subuid_end, Wrtuid_start, Wrtuid_end))
+        printk(KERN_WARNING PREFIX "Subadmin and write-enabled user range "
+               "intersect! Subadmins are able to poke on other subadmins!\n");
+    if(range_intersect_wrt(Netuid, Netuid, Wrtuid_start, Wrtuid_end))
+        printk(KERN_WARNING PREFIX "Netuid within write-enabled user range! "
+               "Subadmin may gain CAP_NET_ADMIN!\n");
+    printk(KERN_INFO "MultiAdmin loaded\n");
+    return 0;
+}
+
+__exit static void multiadm_exit(void) {
+    int ret = 0;
+
+    if(Secondary)
+        ret = mod_unreg_security(BASENAME, &mt_secops);
+    else
+        ret = unregister_security(&mt_secops);
+
+    if(ret != 0)
+        printk(KERN_WARNING PREFIX
+               "Could not unregister with kernel: %d\n", ret);
+
+    return;
+}
+
+module_init(multiadm_init);
+module_exit(multiadm_exit);
+
+//-----------------------------------------------------------------------------
+static int mt_bprm_set_security(struct linux_binprm *bp) {
+    /* In the function chain of exec(), we eventually get here, which is the
+    place to set up new privileges. */
+    cap_bprm_set_security(bp);
+
+    /* All of the following is nicely inlined. The capability raising is
+    resolved to only one instruction for each set. */
+    if(is_any_superadm(bp->e_uid, bp->e_gid)) {
+        chg2_superadm(&bp->cap_permitted);
+        chg2_superadm(&bp->cap_effective);
+    } else if(is_any_superadm(current->uid, current->gid)) {
+        chg2_superadm(&bp->cap_permitted);
+    } else if(is_any_subadm(bp->e_uid, bp->e_gid)) {
+        chg2_subadm(&bp->cap_permitted);
+        chg2_subadm(&bp->cap_effective);
+    } else if(is_any_subadm(current->uid, current->gid)) {
+        chg2_subadm(&bp->cap_permitted);
+    } else if(is_uid_netadm(bp->e_uid)) {
+        chg2_netadm(&bp->cap_permitted);
+        chg2_netadm(&bp->cap_effective);
+    } else if(is_uid_netadm(current->uid)) {
+        chg2_netadm(&bp->cap_permitted);
+    }
+    return 0;
+}
+
+static int mt_cap_extra(int capability) {
+    if(capability == CAP_SYS_ADMIN)
+        /* Subadmin also has CAP_SYS_ADMIN, but if we get here, we did so
+        by capable() -- not capable_light(). */
+        return is_any_superadm(current->euid, current->egid);
+    else
+        /* Subadmin/Netadmin also has other capabilities, but they
+        are -- I hope -- ok. */
+        return 1;
+}
+
+static int mt_inode_permission(struct inode *inode, int mask,
+ struct nameidata *nd)
+{
+    /* Check for superadmin is not done, since the only users that can get
+    here is either superadmin or subadmin. By omitting the check for
+    superadmin, only two comparisons need to be done for the subadmin case.
+    This method is done almost throughout the entire module. */
+
+    if(is_any_subadm(current->euid, current->egid) && (mask & MAY_WRITE)) {
+        int ret;
+        if(inode->i_uid == current->fsuid || is_uid_user(inode->i_uid))
+            return 0;
+
+        /* Since we practically jumped over the checks to get here (because of
+        CAP_DAC_OVERRIDE), we need to do it again. Without CAP_DAC_OVERRIDE
+        this time. Temporarily drop it. */
+        cap_lower(current->cap_effective, CAP_DAC_OVERRIDE);
+
+        // Copied from fs/namei.c
+        if(inode->i_op != NULL && inode->i_op->permission != NULL)
+            ret = inode->i_op->permission(inode, mask & ~MAY_APPEND, nd);
+        else
+            ret = generic_permission(inode, mask & ~MAY_APPEND, NULL);
+
+        cap_raise(current->cap_effective, CAP_DAC_OVERRIDE);
+        return ret;
+    }
+    return 0;
+}
+
+static int mt_inode_setattr(struct dentry *dentry, struct iattr *attr) {
+    if(is_any_subadm(current->euid, current->egid)) {
+        /* Change is only allowed if either the inode belongs to us, or does
+        belond, _and_ will belong in case of ATTR_UID, to a WRT user. */
+        const struct inode *inode = dentry->d_inode;
+        if(inode->i_uid != current->fsuid && !is_uid_user(inode->i_uid))
+            return -EPERM;
+
+        if((attr->ia_valid & ATTR_UID) && attr->ia_uid != current->fsuid &&
+         !is_uid_user(attr->ia_uid))
+                return -EPERM;
+    }
+    return 0;
+}
+
+static int mt_ipc_permission(struct kern_ipc_perm *perm, short flag) {
+    if(is_any_subadm(current->euid, current->egid)) {
+        int req, grant;
+
+        if(perm->uid == current->euid || perm->cuid == current->euid ||
+         is_uid_user(perm->uid) || is_uid_user(perm->cuid))
+                return 0;
+
+        /* Copied and modified from ipc/util.c. Subadmin always has read
+        permission so add S_IRUGO to granted. Checking the owner permission
+        part is not done anymore, because it is done above. */
+        req   = (flag >> 6) | (flag >> 3) | flag;
+        grant = (perm->mode | S_IRUGO) >> 3;
+        if(in_group_p(perm->gid) || in_group_p(perm->cgid))
+            grant >>= 3;
+        if(req & ~grant & 0007)
+            return -EPERM;
+    }
+    return 0;
+}
+
+static int mt_msq_msgctl(struct msg_queue *msq, int cmd) {
+    if(is_any_subadm(current->euid, current->egid)) {
+        if(cmd == MSG_INFO || cmd == MSG_STAT || cmd == IPC_INFO ||
+         cmd == IPC_STAT)
+                return 0;
+
+        // UID or CUID (creator UID) must fit
+        if(msq != NULL && msq->q_perm.uid != current->euid &&
+         msq->q_perm.cuid != current->euid && !is_uid_user(msq->q_perm.uid) &&
+         !is_uid_user(msq->q_perm.cuid))
+                return -EPERM;
+    }
+    return 0;
+}
+
+static int mt_ptrace(task_t *tracer, task_t *task) {
+    if(is_any_subadm(tracer->euid, tracer->egid)) {
+        /* Ownership check according to kernel/ptrace.c:
+        all of [RES][UG]ID must match the tracer's R[UG]ID. */
+        if(task->euid == tracer->uid && task->uid == tracer->uid &&
+         task->suid == tracer->uid && task->egid == tracer->gid &&
+         task->gid == tracer->gid && task->sgid == tracer->gid)
+                return 0;
+
+        // ...or all [RES]UIDs must match a WRT user
+        if(!is_task_user(task))
+            return -EPERM;
+    }
+    return 0;
+}
+
+static int mt_quotactl(int cmd, int type, int id, struct super_block *sb) {
+    if(is_any_subadm(current->euid, current->egid))
+        switch(cmd) {
+            case Q_SYNC:
+            case Q_GETFMT:
+            case Q_GETINFO:
+            case Q_GETQUOTA:
+            case Q_XGETQUOTA:
+            case Q_XGETQSTAT:
+            case Q_XQUOTASYNC:
+                return 0;
+            default:
+                return -EPERM;
+        }
+    return 0;
+}
+
+static int mt_sem_semctl(struct sem_array *sem, int cmd) {
+    if(is_any_subadm(current->euid, current->euid)) {
+        if(cmd == SEM_INFO || cmd == IPC_INFO || cmd == SEM_STAT)
+            return 0;
+        if(sem != NULL) {
+            const struct kern_ipc_perm *perm = &sem->sem_perm;
+            if(perm->uid != current->euid && perm->cuid != current->euid &&
+             !is_uid_user(perm->uid) && !is_uid_user(perm->cuid))
+                    return -EPERM;
+        }
+    }
+    return 0;
+}
+
+static int mt_shm_shmctl(struct shmid_kernel *shp, int cmd) {
+    if(is_any_subadm(current->euid, current->egid)) {
+        if(cmd == SHM_INFO || cmd == SHM_STAT ||
+         cmd == IPC_INFO || cmd == IPC_STAT)
+                return 0;
+        if(shp != NULL) {
+            const struct kern_ipc_perm *perm = &shp->shm_perm;
+            if(perm->uid != current->euid && perm->cuid != current->euid &&
+             !is_uid_user(perm->uid) && !is_uid_user(perm->cuid))
+                    return -EPERM;
+        }
+    }
+    return 0;
+}
+
+static int mt_task_kill(task_t *task, struct siginfo *si, int sig) {
+    if(is_any_subadm(current->euid, current->egid)) {
+        // As tricky as the ptrace() permission net.
+        if(is_uid_user(task->uid) || is_uid_user(task->suid))
+            return 0;
+
+        // Subadmin's own process
+        if(task->uid == current->euid || task->suid == current->euid ||
+         task->uid == current->uid || task->suid == current->uid)
+            return 0;
+
+        // SIG_IGN or a kernel-generated signal
+        if(si != NULL && ((long)si == 1 || (long)si == 2 || !SI_FROMUSER(si)))
+            return 0;
+
+        // For the case of a privileged subshell, but with the same tty
+        if(sig == SIGCONT && task->signal->session == current->signal->session)
+            return 0;
+
+        return -EPERM;
+    }
+    return 0;
+}
+
+static int mt_task_post_setuid(uid_t old_ruid, uid_t old_euid,
+ uid_t old_suid, int flags)
+{
+    int ret = cap_task_post_setuid(old_ruid, old_euid, old_suid, flags);
+    if(ret != 0)
+        return ret;
+
+    switch(flags) {
+        case LSM_SETID_ID:
+        case LSM_SETID_RE:
+        case LSM_SETID_RES:
+            // Unlike bprm_set_security(), effective must be set independently.
+            if(is_uid_superadm(current->uid))
+                chg2_superadm(&current->cap_permitted);
+            else if(is_uid_subadm(current->uid))
+                chg2_subadm(&current->cap_permitted);
+            else if(is_uid_netadm(current->uid))
+                chg2_netadm(&current->cap_permitted);
+
+            if(is_uid_superadm(current->euid))
+                chg2_superadm(&current->cap_effective);
+            else if(is_uid_subadm(current->euid))
+                chg2_subadm(&current->cap_effective);
+            else if(is_uid_netadm(current->euid))
+                chg2_netadm(&current->cap_effective);
+            break;
+    }
+    return 0;
+}
+
+static int mt_task_post_setgid(gid_t old_rgid, gid_t old_egid,
+ gid_t old_sgid, int flags)
+{
+    switch(flags) {
+        case LSM_SETID_ID:
+        case LSM_SETID_RE:
+        case LSM_SETID_RES:
+            if(is_gid_superadm(current->gid))
+                chg2_superadm(&current->cap_permitted);
+            else if(is_gid_subadm(current->gid))
+                chg2_subadm(&current->cap_permitted);
+
+            if(is_gid_superadm(current->egid))
+                chg2_superadm(&current->cap_effective);
+            else if(is_gid_subadm(current->egid))
+                chg2_subadm(&current->cap_effective);
+            break;
+    }
+    return 0;
+}
+
+static int mt_task_setuid(uid_t ruid, uid_t euid, uid_t suid, int flags) {
+    if(is_any_superadm(current->euid, current->egid))
+        return 0;
+
+    if(is_any_subadm(current->euid, current->egid))
+        if((ruid == -1 || is_uid_user(ruid)) && (euid == -1 ||
+         is_uid_user(euid)) && (suid == -1 || is_uid_user(suid)))
+                return 0;
+
+    switch(flags) {
+        case LSM_SETID_ID:
+            if(current->uid == ruid || current->suid == ruid)
+                return 0;
+            break;
+        case LSM_SETID_RE:
+            if(current->euid == ruid || current->euid == euid ||
+             current->uid == ruid || current->uid == euid ||
+             current->suid == euid)
+                    return 0;
+            break;
+        case LSM_SETID_RES:
+            if(current->euid == ruid || current->euid == euid ||
+             current->euid == suid || current->uid == ruid ||
+             current->uid == euid || current->uid == suid ||
+             current->suid == ruid || current->suid == euid ||
+             current->suid == suid)
+                    return 0;
+            break;
+        case LSM_SETID_FS:
+            if(current->euid == ruid)
+                return 0;
+            break;
+        default:
+            printk(KERN_WARNING PREFIX "Unsupported case %d in %s\n",
+                   flags, __FUNCTION__);
+            break;
+    }
+    return -EIO;
+}
+
+static int mt_task_setnice(task_t *task, int nice) {
+    if(is_any_subadm(current->euid, current->egid)) {
+        if(task->euid != current->euid && task->uid != current->euid &&
+         !is_task1_user(task))
+                return -EPERM;
+        if(nice < 0)
+                return -EACCES;
+    }
+    return 0;
+}
+
+static int mt_task_setscheduler(task_t *task, int policy,
+ struct sched_param *param)
+{
+    /* Return 0 for superuser and normal users. The latters' checks are
+    performed in sched.c. */
+    if(is_any_subadm(current->euid, current->egid)) {
+        // Copied from kernel/sched.c:sched_setscheduler()
+        if(task->policy != policy)
+            return -EPERM;
+
+        if(policy != SCHED_NORMAL && param->sched_priority > task->rt_priority &&
+         param->sched_priority > task->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
+                return -EPERM;
+
+        if(task->uid != current->euid && task->suid != current->euid &&
+         !is_task1_user(task))
+                return -EPERM;
+    }
+    return 0;
+}
+
+//-----------------------------------------------------------------------------
+static inline void chg2_superadm(kernel_cap_t *c) {
+    cap_set_full(*c);
+    cap_lower(*c, CAP_SETPCAP);
+    cap_lower(*c, 31); // currently unused
+    return;
+}
+
+static inline void chg2_subadm(kernel_cap_t *c) {
+    cap_clear(*c);
+    cap_raise(*c, CAP_CHOWN);
+    cap_raise(*c, CAP_DAC_OVERRIDE);
+    cap_raise(*c, CAP_DAC_READ_SEARCH);
+    cap_raise(*c, CAP_FOWNER);
+    cap_raise(*c, CAP_KILL);
+    cap_raise(*c, CAP_SETUID);
+    cap_raise(*c, CAP_IPC_OWNER);
+    cap_raise(*c, CAP_SYS_PTRACE);
+    cap_raise(*c, CAP_SYS_ADMIN);
+    cap_raise(*c, CAP_SYS_NICE);
+    return;
+}
+
+static inline void chg2_netadm(kernel_cap_t *c) {
+    cap_clear(*c);
+    cap_raise(*c, CAP_NET_ADMIN);
+    return;
+}
+
+static inline bool is_any_superadm(uid_t u, gid_t g) {
+    return is_uid_superadm(u) || is_gid_superadm(g);
+}
+
+static inline bool is_uid_superadm(uid_t u) {
+    return
+      (!issecure(SECURE_NOROOT) && u == 0) ||
+      (Superuid_start != -1 && Superuid_end != -1 &&
+      u >= Superuid_start && u <= Superuid_end);
+}
+
+static inline bool is_gid_superadm(gid_t g) {
+    return Supergid != -1 && g == Supergid;
+}
+
+static inline bool is_any_subadm(uid_t u, gid_t g) {
+    return is_uid_subadm(u) || is_gid_subadm(g);
+}
+
+static inline bool is_uid_subadm(uid_t u) {
+    return Subuid_start != -1 && Subuid_end != -1 &&
+           u >= Subuid_start && u <= Subuid_end;
+}
+
+static inline bool is_gid_subadm(gid_t g) {
+    return Subgid != -1 && g == Subgid;
+}
+
+static inline bool is_uid_netadm(uid_t u) {
+    return Netuid != -1 && u == Netuid;
+}
+
+static inline bool is_uid_user(uid_t u) {
+    /* Special case Wrtuid_end == (unsigned) -1 means what it means: everything
+    until the end. This is why there is no Wrtuid_end != -1 check. */
+    return Wrtuid_start != -1 && u >= Wrtuid_start && u <= Wrtuid_end;
+}
+
+static inline bool is_task1_user(const task_t *task) {
+    return is_uid_user(task->uid) || is_uid_user(task->suid);
+}
+
+static inline bool is_task_user(const task_t *task) {
+    return is_uid_user(task->euid) && is_uid_user(task->uid) &&
+           is_uid_user(task->suid);
+}
+
+static inline bool range_intersect(uid_t as, uid_t ae, uid_t bs, uid_t be) {
+    if(as == -1 || ae == -1 || bs == -1 || be == -1)
+        return 0;
+    return (long)ae >= (long)bs && (long)as <= (long)be;
+}
+
+static inline bool range_intersect_wrt(uid_t as, uid_t ae,
+ uid_t bs, uid_t be)
+{
+    if(as == -1 || ae == -1 || bs == -1)
+        return 0;
+    return (long)ae >= (long)bs && (long)as <= (long)be;
+}
+
+//=============================================================================
#<<eof>>


Jan Engelhardt
-- 

Re: [PATCH 4/4] MultiAdmin module

[James Morris]

On Mon, 1 May 2006, Jan Engelhardt wrote:

> +#if !defined(CONFIG_SECURITY_CAPABILITIES) && \
> +    !defined(CONFIG_SECURITY_CAPABILITIES_MODULE)
> +#        error You need to have CONFIG_SECURITY_CAPABILITIES=y or =m \
> +               for MultiAdmin to compile successfully.
> +#endif

This is what Kconfig language is for.

> +typedef int bool;

You won't get much worthwile review of this code until you clean it up and 
make it conform to kernel coding style.


- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH 4/4] MultiAdmin module

[Greg KH]

On Mon, May 01, 2006 at 03:50:21PM +0200, Jan Engelhardt wrote:
> 
> [PATCH 4/4] MultiAdmin module
> 
>     -   Add the MultiAdmin to the mainline tree.
>         I hope the rest is self-explanatory.
> 
> Please do not mention CodingStyle for multiadm.c. I already know it. :)
> And I will get to it should it really be merged.

No one will review it if it isn't in the proper CodingStyle.

We have a coding style for a reason, it makes it a very simple thing for
anyone to review the code as the patterns are all the same.  It turns
out that people's brains get trained to ignore the patterns and see the
details instead.  Lots of research backs this up.

So switch to the common coding style, otherwise no one will look at your
code (or if they do, odds are they will miss a lot...)

thanks,

greg k-h

Re: [PATCH 0/4] MultiAdmin LSM

[Arjan van de Ven]

> 2. A small problem
> ==================
> As cool as it may sound, I think the implementation is not as clean as
> possible.
> 
> Let's pick a random starting point: The subadmin is allowed to call
> drivers/char/lp.c:lp_ioctl():LPGETSTATS. Or
> fs/quota.c:generic_quotactl_valid():Q_GET*/Q_XGET*. For that to work
> without too much code changes, CAP_SYS_ADMIN must be given to the
> subadmin.
> 
> However, CAP_SYS_ADMIN (others are affected too, but this is the main one)
> is used for other things too (mostly write or ioctl operations), which is
> actually something that should not be granted to the subadmin.
> 
> This poses a problem. Currently, it is solved by adding an extra LSM hook,
> security_cap_extra(), called from capable(). The hooked function then
> looks at current->*uid/*gid and returns 1 or 0, depending on whether an
> action is allowed or not. For more details see patch #1.
> 
> 


I wonder if we should just split up CAP_SYS_ADMIN then...
that might end up being the most simple solution...

[PATCH 4a/4] MultiAdmin LSM (LKCS'ed)

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 23178 bytes --]



Does Lindented suffice?

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/Kconfig linux-2.6.17-rc3+/security/Kconfig
--- linux-2.6.17-rc3~/security/Kconfig	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/security/Kconfig	2006-05-01 18:00:26.692832000 +0200
@@ -99,6 +99,22 @@ config SECURITY_SECLVL
 
 	  If you are unsure how to answer this question, answer N.
 
+config SECURITY_MULTIADM
+    tristate "MultiAdmin secuirty module"
+    depends on SECURITY
+    ---help---
+        The MultiAdmin security kernel module provides means to have multiple
+        "root" users with unique UIDs. This fixes collation order problems
+        which for example appear with NSCD, allows to have files with
+        determinable owner and allows to track the quota usage for every
+        user, since they now have a unique uid.
+        
+        It also implements a "sub-admin", a partially restricted root user
+        (or enhanced normal user, depending on the way you see it), who has
+        full read-only access to most subsystems, and additional write rights
+        only to a limited subset, e.g. writing to files or killing processes
+        only of certain users.
+
 source security/selinux/Kconfig
 
 endmenu
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/Makefile linux-2.6.17-rc3+/security/Makefile
--- linux-2.6.17-rc3~/security/Makefile	2006-04-27 04:19:25.000000000 +0200
+++ linux-2.6.17-rc3+/security/Makefile	2006-05-01 18:00:26.692832000 +0200
@@ -17,3 +17,4 @@ obj-$(CONFIG_SECURITY_SELINUX)		+= selin
 obj-$(CONFIG_SECURITY_CAPABILITIES)	+= commoncap.o capability.o
 obj-$(CONFIG_SECURITY_ROOTPLUG)		+= commoncap.o root_plug.o
 obj-$(CONFIG_SECURITY_SECLVL)		+= seclvl.o
+obj-$(CONFIG_SECURITY_MULTIADM)		+= commoncap.o multiadm.o
diff --fast -Ndpru -X dontdiff linux-2.6.17-rc3~/security/multiadm.c linux-2.6.17-rc3+/security/multiadm.c
--- linux-2.6.17-rc3~/security/multiadm.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.17-rc3+/security/multiadm.c	2006-05-01 18:01:15.142832000 +0200
@@ -0,0 +1,652 @@
+/*=============================================================================
+| MultiAdmin Security Module                                                  |
+| Copyright © Jan Engelhardt <jengelh [at] gmx de>, 2005 - 2006               |
+| v1.0.5, May 2006                                                            |
+| http://alphagate.hopto.org/                                                 |
+`-----------------------------------------------------------------------------'
+
+    This program is free software; you can redistribute it and/or
+    modify it under the terms of the GNU General Public License
+    version 2 as published by the Free Software Foundation.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+    General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program kit; if not, write to:
+    Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
+    Boston, MA  02110-1301  USA
+=============================================================================*/
+#include <asm/siginfo.h>
+#include <linux/binfmts.h>
+#include <linux/capability.h>
+#include <linux/config.h>
+#include <linux/dcache.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/ipc.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/namei.h>
+#include <linux/sched.h>
+#include <linux/securebits.h>
+#include <linux/security.h>
+#include <linux/sem.h>
+#include <linux/types.h>
+
+#define BASENAME "multiadm"
+#define PREFIX BASENAME ": "
+
+static int mt_bprm_set_security(struct linux_binprm *);
+static int mt_cap_extra(int);
+static int mt_inode_permission(struct inode *, int, struct nameidata *);
+static int mt_inode_setattr(struct dentry *, struct iattr *);
+static int mt_ipc_permission(struct kern_ipc_perm *, short);
+static int mt_msq_msgctl(struct msg_queue *, int);
+static int mt_ptrace(task_t *, task_t *);
+static int mt_quotactl(int, int, int, struct super_block *);
+static int mt_sem_semctl(struct sem_array *, int);
+static int mt_shm_shmctl(struct shmid_kernel *, int);
+static int mt_task_kill(task_t *, struct siginfo *, int);
+static int mt_task_post_setuid(uid_t, uid_t, uid_t, int);
+static int mt_task_post_setgid(gid_t, gid_t, gid_t, int);
+static int mt_task_setnice(task_t *, int);
+static int mt_task_setscheduler(task_t *, int, struct sched_param *);
+static int mt_task_setuid(uid_t, uid_t, uid_t, int);
+
+static inline void chg2_superadm(kernel_cap_t *);
+static inline void chg2_subadm(kernel_cap_t *);
+static inline void chg2_netadm(kernel_cap_t *);
+static inline int is_any_superadm(uid_t, gid_t);
+static inline int is_uid_superadm(uid_t);
+static inline int is_gid_superadm(gid_t);
+static inline int is_any_subadm(uid_t, gid_t);
+static inline int is_uid_subadm(uid_t);
+static inline int is_gid_subadm(gid_t);
+static inline int is_uid_netadm(uid_t);
+static inline int is_uid_user(uid_t);
+static inline int is_task1_user(const task_t *);
+static inline int is_task_user(const task_t *);
+static inline int range_intersect(uid_t, uid_t, uid_t, uid_t);
+static inline int range_intersect_wrt(uid_t, uid_t, uid_t, uid_t);
+
+static struct security_operations mt_secops = {
+	.bprm_apply_creds = cap_bprm_apply_creds,
+	.bprm_set_security = mt_bprm_set_security,
+	.cap_extra = mt_cap_extra,
+	.capable = cap_capable,
+	.capget = cap_capget,
+	.capset_check = cap_capset_check,
+	.capset_set = cap_capset_set,
+	.inode_permission = mt_inode_permission,
+	.inode_setattr = mt_inode_setattr,
+	.ipc_permission = mt_ipc_permission,
+	.msg_queue_msgctl = mt_msq_msgctl,
+	.ptrace = mt_ptrace,
+	.quotactl = mt_quotactl,
+	.sem_semctl = mt_sem_semctl,
+	.shm_shmctl = mt_shm_shmctl,
+	.task_kill = mt_task_kill,
+	.task_post_setuid = mt_task_post_setuid,
+	.task_post_setgid = mt_task_post_setgid,
+	.task_setnice = mt_task_setnice,
+	.task_setscheduler = mt_task_setscheduler,
+	.task_setuid = mt_task_setuid,
+};
+static gid_t Supergid = -1, Subgid = -1;
+static uid_t Superuid_start = 0, Superuid_end = 0,
+    Subuid_start = -1, Subuid_end = -1,
+    Netuid = -1, Wrtuid_start = -1, Wrtuid_end = -1;
+static int Secondary = 0;
+
+MODULE_DESCRIPTION("MultiAdmin Security Module; http://alphagate.hopto.org/");
+MODULE_AUTHOR("Jan Engelhardt <jengelh [at] gmx de>");
+MODULE_LICENSE("GPL");
+module_param(Supergid, int, S_IRUSR | S_IWUSR);
+module_param(Superuid_start, int, S_IRUSR | S_IWUSR);
+module_param(Superuid_end, int, S_IRUSR | S_IWUSR);
+module_param(Subuid_start, int, S_IRUSR | S_IWUSR);
+module_param(Subuid_end, int, S_IRUSR | S_IWUSR);
+module_param(Subgid, int, S_IRUSR | S_IWUSR);
+module_param(Netuid, int, S_IRUSR | S_IWUSR);
+module_param(Wrtuid_start, int, S_IRUGO | S_IWUSR);
+module_param(Wrtuid_end, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(Wrtuid_start, "First UID of the write-enabled user range");
+MODULE_PARM_DESC(Wrtuid_end, "Last UID of the write-enabled user range");
+MODULE_PARM_DESC(Superuid_start, "First UIDs of the superadmin range");
+MODULE_PARM_DESC(Superuid_end, "Last UID of the superadmin range");
+MODULE_PARM_DESC(Supergid, "Superadmin GID");
+MODULE_PARM_DESC(Subuid_start, "First UIDs of the subadmin range");
+MODULE_PARM_DESC(Subuid_end, "Last UID of the subadmin range");
+MODULE_PARM_DESC(Subgid, "Subadmin GID");
+MODULE_PARM_DESC(Netuid, "Netadmin UID");
+
+//-----------------------------------------------------------------------------
+__init static int multiadm_init(void)
+{
+	int eax = 0, ebx = 0;
+	if ((eax = register_security(&mt_secops)) != 0) {
+		if ((ebx = mod_reg_security(BASENAME, &mt_secops)) != 0) {
+			printk(KERN_WARNING PREFIX
+			       "Could not register with kernel: %d, %d\n", eax,
+			       ebx);
+			return ebx;
+		}
+		Secondary = 1;
+	}
+
+	if (range_intersect
+	    (Superuid_start, Superuid_end, Subuid_start, Subuid_end))
+		printk(KERN_WARNING PREFIX
+		       "Superadmin and Subadmin ranges intersect! Unpredictable behavior"
+		       " may result: some operations may classify you as a superadmin,"
+		       " others as a subadmin. Security leak: subadmin could possibly"
+		       " change into superadmin!\n");
+	if (range_intersect(Superuid_start, Superuid_end, Netuid, Netuid))
+		printk(KERN_WARNING PREFIX
+		       "Netuid within superadmin range! -Has more "
+		       "powers than intended!\n");
+	if (range_intersect
+	    (Superuid_start, Superuid_end, Wrtuid_start, Wrtuid_end))
+		printk(KERN_WARNING PREFIX
+		       "Superadmin and write-enabled user range "
+		       "intersect! A subadmin could setuid() into a superadmin!\n");
+	if (range_intersect(Subuid_start, Subuid_end, Netuid, Netuid))
+		printk(KERN_WARNING PREFIX
+		       "Netuid within subadmin range! -Has more "
+		       "powers than intended!\n");
+	if (range_intersect_wrt
+	    (Subuid_start, Subuid_end, Wrtuid_start, Wrtuid_end))
+		printk(KERN_WARNING PREFIX
+		       "Subadmin and write-enabled user range "
+		       "intersect! Subadmins are able to poke on other subadmins!\n");
+	if (range_intersect_wrt(Netuid, Netuid, Wrtuid_start, Wrtuid_end))
+		printk(KERN_WARNING PREFIX
+		       "Netuid within write-enabled user range! "
+		       "Subadmin may gain CAP_NET_ADMIN!\n");
+	printk(KERN_INFO "MultiAdmin loaded\n");
+	return 0;
+}
+
+__exit static void multiadm_exit(void)
+{
+	int ret = 0;
+
+	if (Secondary)
+		ret = mod_unreg_security(BASENAME, &mt_secops);
+	else
+		ret = unregister_security(&mt_secops);
+
+	if (ret != 0)
+		printk(KERN_WARNING PREFIX
+		       "Could not unregister with kernel: %d\n", ret);
+
+	return;
+}
+
+module_init(multiadm_init);
+module_exit(multiadm_exit);
+
+//-----------------------------------------------------------------------------
+static int mt_bprm_set_security(struct linux_binprm *bp)
+{
+	/* In the function chain of exec(), we eventually get here, which is the
+	   place to set up new privileges. */
+	cap_bprm_set_security(bp);
+
+	/* All of the following is nicely inlined. The capability raising is
+	   resolved to only one instruction for each set. */
+	if (is_any_superadm(bp->e_uid, bp->e_gid)) {
+		chg2_superadm(&bp->cap_permitted);
+		chg2_superadm(&bp->cap_effective);
+	} else if (is_any_superadm(current->uid, current->gid)) {
+		chg2_superadm(&bp->cap_permitted);
+	} else if (is_any_subadm(bp->e_uid, bp->e_gid)) {
+		chg2_subadm(&bp->cap_permitted);
+		chg2_subadm(&bp->cap_effective);
+	} else if (is_any_subadm(current->uid, current->gid)) {
+		chg2_subadm(&bp->cap_permitted);
+	} else if (is_uid_netadm(bp->e_uid)) {
+		chg2_netadm(&bp->cap_permitted);
+		chg2_netadm(&bp->cap_effective);
+	} else if (is_uid_netadm(current->uid)) {
+		chg2_netadm(&bp->cap_permitted);
+	}
+	return 0;
+}
+
+static int mt_cap_extra(int capability)
+{
+	if (capability == CAP_SYS_ADMIN)
+		/* Subadmin also has CAP_SYS_ADMIN, but if we get here, we did so
+		   by capable() -- not capable_light(). */
+		return is_any_superadm(current->euid, current->egid);
+	else
+		/* Subadmin/Netadmin also has other capabilities, but they
+		   are -- I hope -- ok. */
+		return 1;
+}
+
+static int mt_inode_permission(struct inode *inode, int mask,
+			       struct nameidata *nd)
+{
+	/* Check for superadmin is not done, since the only users that can get
+	   here is either superadmin or subadmin. By omitting the check for
+	   superadmin, only two comparisons need to be done for the subadmin case.
+	   This method is done almost throughout the entire module. */
+
+	if (is_any_subadm(current->euid, current->egid) && (mask & MAY_WRITE)) {
+		int ret;
+		if (inode->i_uid == current->fsuid || is_uid_user(inode->i_uid))
+			return 0;
+
+		/* Since we practically jumped over the checks to get here (because of
+		   CAP_DAC_OVERRIDE), we need to do it again. Without CAP_DAC_OVERRIDE
+		   this time. Temporarily drop it. */
+		cap_lower(current->cap_effective, CAP_DAC_OVERRIDE);
+
+		// Copied from fs/namei.c
+		if (inode->i_op != NULL && inode->i_op->permission != NULL)
+			ret =
+			    inode->i_op->permission(inode, mask & ~MAY_APPEND,
+						    nd);
+		else
+			ret =
+			    generic_permission(inode, mask & ~MAY_APPEND, NULL);
+
+		cap_raise(current->cap_effective, CAP_DAC_OVERRIDE);
+		return ret;
+	}
+	return 0;
+}
+
+static int mt_inode_setattr(struct dentry *dentry, struct iattr *attr)
+{
+	if (is_any_subadm(current->euid, current->egid)) {
+		/* Change is only allowed if either the inode belongs to us, or does
+		   belond, _and_ will belong in case of ATTR_UID, to a WRT user. */
+		const struct inode *inode = dentry->d_inode;
+		if (inode->i_uid != current->fsuid
+		    && !is_uid_user(inode->i_uid))
+			return -EPERM;
+
+		if ((attr->ia_valid & ATTR_UID)
+		    && attr->ia_uid != current->fsuid
+		    && !is_uid_user(attr->ia_uid))
+			return -EPERM;
+	}
+	return 0;
+}
+
+static int mt_ipc_permission(struct kern_ipc_perm *perm, short flag)
+{
+	if (is_any_subadm(current->euid, current->egid)) {
+		int req, grant;
+
+		if (perm->uid == current->euid || perm->cuid == current->euid ||
+		    is_uid_user(perm->uid) || is_uid_user(perm->cuid))
+			return 0;
+
+		/* Copied and modified from ipc/util.c. Subadmin always has read
+		   permission so add S_IRUGO to granted. Checking the owner permission
+		   part is not done anymore, because it is done above. */
+		req = (flag >> 6) | (flag >> 3) | flag;
+		grant = (perm->mode | S_IRUGO) >> 3;
+		if (in_group_p(perm->gid) || in_group_p(perm->cgid))
+			grant >>= 3;
+		if (req & ~grant & 0007)
+			return -EPERM;
+	}
+	return 0;
+}
+
+static int mt_msq_msgctl(struct msg_queue *msq, int cmd)
+{
+	if (is_any_subadm(current->euid, current->egid)) {
+		if (cmd == MSG_INFO || cmd == MSG_STAT || cmd == IPC_INFO ||
+		    cmd == IPC_STAT)
+			return 0;
+
+		// UID or CUID (creator UID) must fit
+		if (msq != NULL && msq->q_perm.uid != current->euid &&
+		    msq->q_perm.cuid != current->euid
+		    && !is_uid_user(msq->q_perm.uid)
+		    && !is_uid_user(msq->q_perm.cuid))
+			return -EPERM;
+	}
+	return 0;
+}
+
+static int mt_ptrace(task_t * tracer, task_t * task)
+{
+	if (is_any_subadm(tracer->euid, tracer->egid)) {
+		/* Ownership check according to kernel/ptrace.c:
+		   all of [RES][UG]ID must match the tracer's R[UG]ID. */
+		if (task->euid == tracer->uid && task->uid == tracer->uid &&
+		    task->suid == tracer->uid && task->egid == tracer->gid &&
+		    task->gid == tracer->gid && task->sgid == tracer->gid)
+			return 0;
+
+		// ...or all [RES]UIDs must match a WRT user
+		if (!is_task_user(task))
+			return -EPERM;
+	}
+	return 0;
+}
+
+static int mt_quotactl(int cmd, int type, int id, struct super_block *sb)
+{
+	if (is_any_subadm(current->euid, current->egid))
+		switch (cmd) {
+		case Q_SYNC:
+		case Q_GETFMT:
+		case Q_GETINFO:
+		case Q_GETQUOTA:
+		case Q_XGETQUOTA:
+		case Q_XGETQSTAT:
+		case Q_XQUOTASYNC:
+			return 0;
+		default:
+			return -EPERM;
+		}
+	return 0;
+}
+
+static int mt_sem_semctl(struct sem_array *sem, int cmd)
+{
+	if (is_any_subadm(current->euid, current->euid)) {
+		if (cmd == SEM_INFO || cmd == IPC_INFO || cmd == SEM_STAT)
+			return 0;
+		if (sem != NULL) {
+			const struct kern_ipc_perm *perm = &sem->sem_perm;
+			if (perm->uid != current->euid
+			    && perm->cuid != current->euid
+			    && !is_uid_user(perm->uid)
+			    && !is_uid_user(perm->cuid))
+				return -EPERM;
+		}
+	}
+	return 0;
+}
+
+static int mt_shm_shmctl(struct shmid_kernel *shp, int cmd)
+{
+	if (is_any_subadm(current->euid, current->egid)) {
+		if (cmd == SHM_INFO || cmd == SHM_STAT ||
+		    cmd == IPC_INFO || cmd == IPC_STAT)
+			return 0;
+		if (shp != NULL) {
+			const struct kern_ipc_perm *perm = &shp->shm_perm;
+			if (perm->uid != current->euid
+			    && perm->cuid != current->euid
+			    && !is_uid_user(perm->uid)
+			    && !is_uid_user(perm->cuid))
+				return -EPERM;
+		}
+	}
+	return 0;
+}
+
+static int mt_task_kill(task_t * task, struct siginfo *si, int sig)
+{
+	if (is_any_subadm(current->euid, current->egid)) {
+		// As tricky as the ptrace() permission net.
+		if (is_uid_user(task->uid) || is_uid_user(task->suid))
+			return 0;
+
+		// Subadmin's own process
+		if (task->uid == current->euid || task->suid == current->euid ||
+		    task->uid == current->uid || task->suid == current->uid)
+			return 0;
+
+		// SIG_IGN or a kernel-generated signal
+		if (si != NULL
+		    && ((long)si == 1 || (long)si == 2 || !SI_FROMUSER(si)))
+			return 0;
+
+		// For the case of a privileged subshell, but with the same tty
+		if (sig == SIGCONT
+		    && task->signal->session == current->signal->session)
+			return 0;
+
+		return -EPERM;
+	}
+	return 0;
+}
+
+static int mt_task_post_setuid(uid_t old_ruid, uid_t old_euid,
+			       uid_t old_suid, int flags)
+{
+	int ret = cap_task_post_setuid(old_ruid, old_euid, old_suid, flags);
+	if (ret != 0)
+		return ret;
+
+	switch (flags) {
+	case LSM_SETID_ID:
+	case LSM_SETID_RE:
+	case LSM_SETID_RES:
+		// Unlike bprm_set_security(), effective must be set independently.
+		if (is_uid_superadm(current->uid))
+			chg2_superadm(&current->cap_permitted);
+		else if (is_uid_subadm(current->uid))
+			chg2_subadm(&current->cap_permitted);
+		else if (is_uid_netadm(current->uid))
+			chg2_netadm(&current->cap_permitted);
+
+		if (is_uid_superadm(current->euid))
+			chg2_superadm(&current->cap_effective);
+		else if (is_uid_subadm(current->euid))
+			chg2_subadm(&current->cap_effective);
+		else if (is_uid_netadm(current->euid))
+			chg2_netadm(&current->cap_effective);
+		break;
+	}
+	return 0;
+}
+
+static int mt_task_post_setgid(gid_t old_rgid, gid_t old_egid,
+			       gid_t old_sgid, int flags)
+{
+	switch (flags) {
+	case LSM_SETID_ID:
+	case LSM_SETID_RE:
+	case LSM_SETID_RES:
+		if (is_gid_superadm(current->gid))
+			chg2_superadm(&current->cap_permitted);
+		else if (is_gid_subadm(current->gid))
+			chg2_subadm(&current->cap_permitted);
+
+		if (is_gid_superadm(current->egid))
+			chg2_superadm(&current->cap_effective);
+		else if (is_gid_subadm(current->egid))
+			chg2_subadm(&current->cap_effective);
+		break;
+	}
+	return 0;
+}
+
+static int mt_task_setuid(uid_t ruid, uid_t euid, uid_t suid, int flags)
+{
+	if (is_any_superadm(current->euid, current->egid))
+		return 0;
+
+	if (is_any_subadm(current->euid, current->egid))
+		if ((ruid == -1 || is_uid_user(ruid)) && (euid == -1 ||
+							  is_uid_user(euid))
+		    && (suid == -1 || is_uid_user(suid)))
+			return 0;
+
+	switch (flags) {
+	case LSM_SETID_ID:
+		if (current->uid == ruid || current->suid == ruid)
+			return 0;
+		break;
+	case LSM_SETID_RE:
+		if (current->euid == ruid || current->euid == euid ||
+		    current->uid == ruid || current->uid == euid ||
+		    current->suid == euid)
+			return 0;
+		break;
+	case LSM_SETID_RES:
+		if (current->euid == ruid || current->euid == euid ||
+		    current->euid == suid || current->uid == ruid ||
+		    current->uid == euid || current->uid == suid ||
+		    current->suid == ruid || current->suid == euid ||
+		    current->suid == suid)
+			return 0;
+		break;
+	case LSM_SETID_FS:
+		if (current->euid == ruid)
+			return 0;
+		break;
+	default:
+		printk(KERN_WARNING PREFIX "Unsupported case %d in %s\n",
+		       flags, __FUNCTION__);
+		break;
+	}
+	return -EIO;
+}
+
+static int mt_task_setnice(task_t * task, int nice)
+{
+	if (is_any_subadm(current->euid, current->egid)) {
+		if (task->euid != current->euid && task->uid != current->euid &&
+		    !is_task1_user(task))
+			return -EPERM;
+		if (nice < 0)
+			return -EACCES;
+	}
+	return 0;
+}
+
+static int mt_task_setscheduler(task_t * task, int policy,
+				struct sched_param *param)
+{
+	/* Return 0 for superuser and normal users. The latters' checks are
+	   performed in sched.c. */
+	if (is_any_subadm(current->euid, current->egid)) {
+		// Copied from kernel/sched.c:sched_setscheduler()
+		if (task->policy != policy)
+			return -EPERM;
+
+		if (policy != SCHED_NORMAL
+		    && param->sched_priority > task->rt_priority
+		    && param->sched_priority >
+		    task->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
+			return -EPERM;
+
+		if (task->uid != current->euid && task->suid != current->euid &&
+		    !is_task1_user(task))
+			return -EPERM;
+	}
+	return 0;
+}
+
+//-----------------------------------------------------------------------------
+static inline void chg2_superadm(kernel_cap_t * c)
+{
+	cap_set_full(*c);
+	cap_lower(*c, CAP_SETPCAP);
+	cap_lower(*c, 31);	// currently unused
+	return;
+}
+
+static inline void chg2_subadm(kernel_cap_t * c)
+{
+	cap_clear(*c);
+	cap_raise(*c, CAP_CHOWN);
+	cap_raise(*c, CAP_DAC_OVERRIDE);
+	cap_raise(*c, CAP_DAC_READ_SEARCH);
+	cap_raise(*c, CAP_FOWNER);
+	cap_raise(*c, CAP_KILL);
+	cap_raise(*c, CAP_SETUID);
+	cap_raise(*c, CAP_IPC_OWNER);
+	cap_raise(*c, CAP_SYS_PTRACE);
+	cap_raise(*c, CAP_SYS_ADMIN);
+	cap_raise(*c, CAP_SYS_NICE);
+	return;
+}
+
+static inline void chg2_netadm(kernel_cap_t * c)
+{
+	cap_clear(*c);
+	cap_raise(*c, CAP_NET_ADMIN);
+	return;
+}
+
+static inline int is_any_superadm(uid_t u, gid_t g)
+{
+	return is_uid_superadm(u) || is_gid_superadm(g);
+}
+
+static inline int is_uid_superadm(uid_t u)
+{
+	return
+	    (!issecure(SECURE_NOROOT) && u == 0) ||
+	    (Superuid_start != -1 && Superuid_end != -1 &&
+	     u >= Superuid_start && u <= Superuid_end);
+}
+
+static inline int is_gid_superadm(gid_t g)
+{
+	return Supergid != -1 && g == Supergid;
+}
+
+static inline int is_any_subadm(uid_t u, gid_t g)
+{
+	return is_uid_subadm(u) || is_gid_subadm(g);
+}
+
+static inline int is_uid_subadm(uid_t u)
+{
+	return Subuid_start != -1 && Subuid_end != -1 &&
+	    u >= Subuid_start && u <= Subuid_end;
+}
+
+static inline int is_gid_subadm(gid_t g)
+{
+	return Subgid != -1 && g == Subgid;
+}
+
+static inline int is_uid_netadm(uid_t u)
+{
+	return Netuid != -1 && u == Netuid;
+}
+
+static inline int is_uid_user(uid_t u)
+{
+	/* Special case Wrtuid_end == (unsigned) -1 means what it means: everything
+	   until the end. This is why there is no Wrtuid_end != -1 check. */
+	return Wrtuid_start != -1 && u >= Wrtuid_start && u <= Wrtuid_end;
+}
+
+static inline int is_task1_user(const task_t * task)
+{
+	return is_uid_user(task->uid) || is_uid_user(task->suid);
+}
+
+static inline int is_task_user(const task_t * task)
+{
+	return is_uid_user(task->euid) && is_uid_user(task->uid) &&
+	    is_uid_user(task->suid);
+}
+
+static inline int range_intersect(uid_t as, uid_t ae, uid_t bs, uid_t be)
+{
+	if (as == -1 || ae == -1 || bs == -1 || be == -1)
+		return 0;
+	return (long)ae >= (long)bs && (long)as <= (long)be;
+}
+
+static inline int range_intersect_wrt(uid_t as, uid_t ae, uid_t bs, uid_t be)
+{
+	if (as == -1 || ae == -1 || bs == -1)
+		return 0;
+	return (long)ae >= (long)bs && (long)as <= (long)be;
+}
+
+//=============================================================================


Jan Engelhardt
-- 

Re: [PATCH 4a/4] MultiAdmin LSM (LKCS'ed)

[Greg KH]

On Mon, May 01, 2006 at 06:03:09PM +0200, Jan Engelhardt wrote:
> 
> 
> Does Lindented suffice?

It's a good start, but you still need to fix things like:

> +#include <asm/siginfo.h>
> +#include <linux/binfmts.h>
> +#include <linux/capability.h>
> +#include <linux/config.h>
> +#include <linux/dcache.h>
> +#include <linux/file.h>
> +#include <linux/fs.h>
> +#include <linux/init.h>
> +#include <linux/ipc.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/namei.h>
> +#include <linux/sched.h>
> +#include <linux/securebits.h>
> +#include <linux/security.h>
> +#include <linux/sem.h>
> +#include <linux/types.h>

asm #include goes last.

> +static inline void chg2_superadm(kernel_cap_t *);
> +static inline void chg2_subadm(kernel_cap_t *);
> +static inline void chg2_netadm(kernel_cap_t *);
> +static inline int is_any_superadm(uid_t, gid_t);
> +static inline int is_uid_superadm(uid_t);
> +static inline int is_gid_superadm(gid_t);
> +static inline int is_any_subadm(uid_t, gid_t);
> +static inline int is_uid_subadm(uid_t);
> +static inline int is_gid_subadm(gid_t);
> +static inline int is_uid_netadm(uid_t);
> +static inline int is_uid_user(uid_t);
> +static inline int is_task1_user(const task_t *);
> +static inline int is_task_user(const task_t *);
> +static inline int range_intersect(uid_t, uid_t, uid_t, uid_t);
> +static inline int range_intersect_wrt(uid_t, uid_t, uid_t, uid_t);

inline functions don't need definitions like this.

> +static gid_t Supergid = -1, Subgid = -1;
> +static uid_t Superuid_start = 0, Superuid_end = 0,
> +    Subuid_start = -1, Subuid_end = -1,
> +    Netuid = -1, Wrtuid_start = -1, Wrtuid_end = -1;
> +static int Secondary = 0;

Variables do not have capital letters.

thanks,

greg k-h

Re: [PATCH 4a/4] MultiAdmin LSM (LKCS'ed)

[Jan Engelhardt]

>asm #include goes last.

How come?

>> +static inline int range_intersect_wrt(uid_t, uid_t, uid_t, uid_t);
>
>inline functions don't need definitions like this.

If memory serves right, callees mentioned below their callers need a 
prototype.

>> +static gid_t Supergid = -1, Subgid = -1;
>> +static uid_t Superuid_start = 0, Superuid_end = 0,
>> +    Subuid_start = -1, Subuid_end = -1,
>> +    Netuid = -1, Wrtuid_start = -1, Wrtuid_end = -1;
>> +static int Secondary = 0;
>
>Variables do not have capital letters.

Who has, besides macros, if anything?



Jan Engelhardt
-- 

Re: [PATCH 4a/4] MultiAdmin LSM (LKCS'ed)

[Greg KH]

On Mon, May 01, 2006 at 07:42:33PM +0200, Jan Engelhardt wrote:
> 
> >asm #include goes last.
> 
> How come?

Just the standard style.

> >> +static inline int range_intersect_wrt(uid_t, uid_t, uid_t, uid_t);
> >
> >inline functions don't need definitions like this.
> 
> If memory serves right, callees mentioned below their callers need a 
> prototype.

You can't have a inline function with a prototype :)

> >> +static gid_t Supergid = -1, Subgid = -1;
> >> +static uid_t Superuid_start = 0, Superuid_end = 0,
> >> +    Subuid_start = -1, Subuid_end = -1,
> >> +    Netuid = -1, Wrtuid_start = -1, Wrtuid_end = -1;
> >> +static int Secondary = 0;
> >
> >Variables do not have capital letters.
> 
> Who has, besides macros, if anything?

nothing.

thanks,

greg k-h

Re: [PATCH 4a/4] MultiAdmin LSM (LKCS'ed)

[Jan Engelhardt]

>
>> >> +static inline int range_intersect_wrt(uid_t, uid_t, uid_t, uid_t);
>> >
>> >inline functions don't need definitions like this.
>> 
>> If memory serves right, callees mentioned below their callers need a 
>> prototype.
>
>You can't have a inline function with a prototype :)

Says who? The file is the best example that one can X-].
(Of course, it requires -funit-at-a-time.)


Jan Engelhardt
-- 

Re: [PATCH 4a/4] MultiAdmin LSM (LKCS'ed)

[Adrian Bunk]

On Mon, May 01, 2006 at 10:19:14PM +0200, Jan Engelhardt wrote:
> >
> >> >> +static inline int range_intersect_wrt(uid_t, uid_t, uid_t, uid_t);
> >> >
> >> >inline functions don't need definitions like this.
> >> 
> >> If memory serves right, callees mentioned below their callers need a 
> >> prototype.
> >
> >You can't have a inline function with a prototype :)
> 
> Says who? The file is the best example that one can X-].
> (Of course, it requires -funit-at-a-time.)

IOW, you know that your code will not compile in the kernel on i386 with 
gcc 3.3 or 3.4.

> Jan Engelhardt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 0/4] MultiAdmin LSM

[Pavel Machek]

Hi!

> Subject: [PATCH 0/4] MultiAdmin LSM
>          (was: Re: Time to remove LSM
>          (was: Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks))
> 
> 
> 0. Preface
> ==========
> Thanks to Greg who, requiring me to post more-split patches, made me
> reconsider the code. I did nothing less than to simplified the whole patch
> cruft (shrunk by factor 10) and removed what seemed unreasonable. This
> thread posts MultiAdmin *1.0.5*.
> 
> 
> 
> 1. Super-short description
> ==========================
> Three user classes exist (determined by user-defined UID ranges),
>     - superadmin, the usual "root"
>     - subadmin
>     - normal users
> 
> A usual (non-multiadm,non-selinux) system has only one superadmin (UID 0)
> and a number of normal users, and the superadmin can operate on
> everything.
> 
> The "subadmin" can read in some superadmin-only places, and is allowed to
> fully operate on processes/files/ipc/etc. of normal users. The full list
> (possibly incomplete) of permissions is available in the README.txt
> (includes short description) in the out-of-tree tarball.
> [http://freshmeat.net/p/multiadm/]

I guess you should really split CAP_SYS_ADMIN into some subsets that
make sense... along with explanation why subsets are 'right'.

							Pavel
-- 
Thanks, Sharp!

Re: [PATCH 0/4] MultiAdmin LSM

[James Morris]

This module implements two distinct ideas:

(1) Multiple superusers with distinct UIDs.

More than one root on a system I think is generally regarded as a bad 
idea.  I'm not sure why you'd use a scheme like this instead of, say, sudo 
or custom setuid helpers for specific tasks -- whatever the case, I think 
such issues can be addressed entirely in userspace.


(2) Partially decomposing the superuser and protecting some users from 
    some decomposed superusers, and decomposing CAP_SYS_ADMIN.

This is a special-case security policy hard-coded into the kernel.  It 
lacks a clear design rationale, and does not seem amenable to analysis, as 
its access control coverage is incomplete.

As already suggested, it may be worth looking at just decomposing 
CAP_SYS_ADMIN, although it's not clear how do to this correctly for the 
general case.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Fri, 2006-04-21 at 15:30 +0200, Jan Engelhardt wrote:
> >> >> Well then, have a look at http://alphagate.hopto.org/multiadm/
> >> >
> >> >hmm on first sight that seems to be basically an extension to the
> >> >existing capability() code... rather than a 'real' LSM module. Am I
> >> >missing something here?
> >> 
> >> (So what's the definition for a "real" LSM module?)
> >
> >No idea, try submitting the patch :)
> >
> Because it's too big, you only get URLs:
> 
> [01/02] http://alphagate.hopto.org/multiadm/mtadm_hooks-2.6.17-rc2.diff  137KB
> [02/02] http://alphagate.hopto.org/multiadm/mtadm_module-2.6.17-rc2.diff  27KB

For proper submission, you should split it up, e.g. one patch per new
hook you need and then your module.

The bulk of the first patch appears to be capable -> capable_x changes.
What is the purpose of that?

The set_task_ioprio hook looks legitimate; should be submitted
separately, modulo CodingStyle issues.

What's the rationale for the int->gid_t and int->uid_t changes in sys?

Some of the hooks used to exist in LSM patches but didn't have a real
user for merging at the time.  But it isn't clear whether you actually
need separate hooks for each of them or if they are being mapped to the
same check in many cases - can it be abstracted to a common hook?

Seems like you are duplicating a lot of the base DAC logic in the
process; would be nice to encapsulate that in the core kernel, and then
just use a common helper in both cases?

> Don't mention CodingStyle, I know. This is just a post to respond to the
> topic on why noone submitted it earlier.
> I already see it coming...

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Jan Engelhardt]

>
>The bulk of the first patch appears to be capable -> capable_x changes.
>What is the purpose of that?
>
When you grant CAP_SYS_ADMIN to a user, he can do _a lot_ of things. I wanted
to have the sub-admin have read rights in most places (e.g. nvram to pick a
random example), but not to have write rights. Unfortunately, read rights and
write rights for nvram both fall under CAP_SYS_ADMIN.

capable_x will call out to security_cap_extra(), passing it the current
function name as a string. An LSM module can then provide security_cap_extra
via the security_operations vector and decide whether to allow the request. I
primarily did this because it reduces the amount of recompiling needed. For
example, instead of having to add a ->nvram_allow_read and ->nvram_allow_write
hooks in include/linux/security.h -- which requires compilation of a lot of
parts -- I can simply use strcmp(func, "nvram_read") in the LSM. I agree that
this is not optimal, but having 1000 pointers in the security_ops vector is not
a solution either (-> code bloat).

>What's the rationale for the int->gid_t and int->uid_t changes in sys?
>

I don't know, but there must be a reason uid_t and gid_t exist in the kernel in
the first place.

>From a technical point, gid_t and uid_t are unsigned, while int is not.

>Some of the hooks used to exist in LSM patches but didn't have a real
>user for merging at the time.  But it isn't clear whether you actually
>need separate hooks for each of them or if they are being mapped to the
>same check in many cases - can it be abstracted to a common hook?

Not without passing a handful of useless parameters (NULL or 0) to each
function.
As much as I would like to combine for example mt_sb_mount and mt_sb_pivotroot,
the prototypes are just too different.
Suggestions welcome.

>Seems like you are duplicating a lot of the base DAC logic in the
>process; would be nice to encapsulate that in the core kernel, and then
>just use a common helper in both cases?

The problem is that the base DAC logic is done after security_*(). Sometimes
that's good, most of the times, it leads to duplicated DAC logic because the
"usual DAC decision" is part of how multiadm decides.

Suggestions welcome too.



Jan Engelhardt
-- 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley]

On Fri, 2006-04-21 at 20:57 +0200, Jan Engelhardt wrote:
> When you grant CAP_SYS_ADMIN to a user, he can do _a lot_ of things. I wanted
> to have the sub-admin have read rights in most places (e.g. nvram to pick a
> random example), but not to have write rights. Unfortunately, read rights and
> write rights for nvram both fall under CAP_SYS_ADMIN.
> 
> capable_x will call out to security_cap_extra(), passing it the current
> function name as a string. An LSM module can then provide security_cap_extra
> via the security_operations vector and decide whether to allow the request. I
> primarily did this because it reduces the amount of recompiling needed. For
> example, instead of having to add a ->nvram_allow_read and ->nvram_allow_write
> hooks in include/linux/security.h -- which requires compilation of a lot of
> parts -- I can simply use strcmp(func, "nvram_read") in the LSM. I agree that
> this is not optimal, but having 1000 pointers in the security_ops vector is not
> a solution either (-> code bloat).

- Where is the user of the cap_extra hook?  I don't see it in multiadm.
If you aren't using it, it isn't a requirement for multiadm, obviously;
you should drop those diffs out and just focus on what you need for
multiadm itself.
- Writing a security module based on function names in other modules is
obviously very fragile; some kind of abstraction would be required.

> >Some of the hooks used to exist in LSM patches but didn't have a real
> >user for merging at the time.  But it isn't clear whether you actually
> >need separate hooks for each of them or if they are being mapped to the
> >same check in many cases - can it be abstracted to a common hook?
> 
> Not without passing a handful of useless parameters (NULL or 0) to each
> function.
> As much as I would like to combine for example mt_sb_mount and mt_sb_pivotroot,
> the prototypes are just too different.
> Suggestions welcome.

I wasn't suggesting passing the union of their parameters, just the ones
that are actually used by your module (plus any parameters used by any
other in-tree user, i.e. capability and SELinux).  And trying to
abstract a higher level conceptual operation as the hook rather than
making them per-syscall/operation.  I know that LSM currently does
things the other way, but I'd much rather see it move toward more
general permission checking interfaces (ala the internal SELinux ones,
although I understand those specific interfaces aren't what you would
use).  Others may have a different POV.

> >Seems like you are duplicating a lot of the base DAC logic in the
> >process; would be nice to encapsulate that in the core kernel, and then
> >just use a common helper in both cases?
> 
> The problem is that the base DAC logic is done after security_*(). Sometimes
> that's good, most of the times, it leads to duplicated DAC logic because the
> "usual DAC decision" is part of how multiadm decides.
> 
> Suggestions welcome too.

At least for common cases like permission(9) and ipcperms(9), the
security hook call comes after the DAC checking.  But not always.
Sounds like you want authoritative hooks, which were discussed and
experimented with during LSM development, see archives.  You could
attempt to revive that for the cases where you need it, moving the
checking into the commoncap functions (defining new ones where needed,
and making sure that existing modules call them so that they still apply
those checks) and calling those functions rather than duplicating the
logic in your own module.  You presumably don't want to have to maintain
the duplicated logic in your own module.

-- 
Stephen Smalley
National Security Agency

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Jan Engelhardt]

>> When you grant CAP_SYS_ADMIN to a user, he can do _a lot_ of things. I wanted
>> to have the sub-admin have read rights in most places (e.g. nvram to pick a
>> random example), but not to have write rights. Unfortunately, read rights and
>> write rights for nvram both fall under CAP_SYS_ADMIN.
>> 
>> capable_x will call out to security_cap_extra(), passing it the current
>> function name as a string. An LSM module can then provide security_cap_extra
>> via the security_operations vector and decide whether to allow the request. I
>> primarily did this because it reduces the amount of recompiling needed. For
>> example, instead of having to add a ->nvram_allow_read and ->nvram_allow_write
>> hooks in include/linux/security.h -- which requires compilation of a lot of
>> parts -- I can simply use strcmp(func, "nvram_read") in the LSM. I agree that
>> this is not optimal, but having 1000 pointers in the security_ops vector is not
>> a solution either (-> code bloat).
>
>- Where is the user of the cap_extra hook?  I don't see it in multiadm.
>If you aren't using it, it isn't a requirement for multiadm, obviously;
>you should drop those diffs out and just focus on what you need for
>multiadm itself.

The subadmin gets CAP_SYS_ADMIN. This is because capable() is often done before
the LSM callout, e.g. sys_sethostname(). Even when capable() is after an LSM
call, the process needs a certain capability or the syscall/function will
return failure to userspace. The best solution I can think of is that capable()
disappears entirely from functions and that an LSM function does it all then.

>- Writing a security module based on function names in other modules is
>obviously very fragile; some kind of abstraction would be required.

Yes, but at least it returns permission denied in the default case :)
Best would probably if the caller uses a fixed string rather than __FUNCTION__
from the expanded capable_x() macro. Or an enum value...

enum {
	HK_SETHOSTNAME,
};

>> >Some of the hooks used to exist in LSM patches but didn't have a real
>> >user for merging at the time.  But it isn't clear whether you actually
>> >need separate hooks for each of them or if they are being mapped to the
>> >same check in many cases - can it be abstracted to a common hook?
>> 
>> Not without passing a handful of useless parameters (NULL or 0) to each
>> function.
>> As much as I would like to combine for example mt_sb_mount and mt_sb_pivotroot,
>> the prototypes are just too different.
>> Suggestions welcome.
>
>I wasn't suggesting passing the union of their parameters, just the ones
>that are actually used by your module (plus any parameters used by any
>other in-tree user, i.e. capability and SELinux).

static bool mt_file_alloc_override(int cur, int max) {
    /* Called when the maximum number of files is open. Only superadmins may
    override this. Return >0 for success. */
    return is_any_superadm(current->euid, current->egid);
}

I see what you mean - cur and max are unused. However, if I was to call to a
seconday module from within this function (which is not really implemented), I
would suddenly need cur and max again. I do think that the parameters have a
reason to be there - a user might wish to enforce this sort:

    return is_any_superadm(...) ||
           (is_any_subadm(...) && (max <= 2048))

E.g. "allow some more" for subadms. Multiadmin is currently extremely tailored
to one specific (call it the default :-) use case.

>And trying to abstract a higher level conceptual operation as the hook rather
>than making them per-syscall/operation.  I know that LSM currently does things
>the other way, but I'd much rather see it move toward more general permission
>checking interfaces (ala the internal SELinux ones, although I understand
>those specific interfaces aren't what you would use).  Others may have a
>different POV.
>
>> >Seems like you are duplicating a lot of the base DAC logic in the
>> >process; would be nice to encapsulate that in the core kernel, and then
>> >just use a common helper in both cases?
>> 
>> The problem is that the base DAC logic is done after security_*(). Sometimes
>> that's good, most of the times, it leads to duplicated DAC logic because the
>> "usual DAC decision" is part of how multiadm decides.
>> 
>> Suggestions welcome too.
>
>At least for common cases like permission(9) and ipcperms(9), the
>security hook call comes after the DAC checking.  But not always.
>Sounds like you want authoritative hooks, which were discussed and
>experimented with during LSM development, see archives.  You could
>attempt to revive that for the cases where you need it, moving the
>checking into the commoncap functions (defining new ones where needed,
>and making sure that existing modules call them so that they still apply
>those checks) and calling those functions rather than duplicating the
>logic in your own module.  You presumably don't want to have to maintain
>the duplicated logic in your own module.

Exactly (like above with capable(), DAC shares the same 'positional' problem).
In fact, after some thought I could come to the conclusion that the POSIX
CAPability framework is more a hindrance for this sort of LSM, since it's
mostly UID/GID-based. We only raise capabilities so the rest of the kernel
plays fine with us.


Jan Engelhardt
-- 

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Pavel Machek]

On Wed 19-04-06 21:06:57, Jan Engelhardt wrote:
> >> 
> >> Well then, have a look at http://alphagate.hopto.org/multiadm/
> >> 
> >
> >hmm on first sight that seems to be basically an extension to the
> >existing capability() code... rather than a 'real' LSM module. Am I
> >missing something here?
> >
> 
> (So what's the definition for a "real" LSM module?)
> 
> It's quite a "big" extension to the capability code inasfar as that 
> access is not solely granted based on capabilities, but a matrix of 
> capabilities plus UID/GID of filesystem objects.
> 
> This is not a "for fun" LSM like rootplug, but it was specifically 
> developed to address some permission issues in an educational institution. 
> The LSM hooks were there (and some more are added with MultiAdm), and it 
> seemed a lot simpler than setting up SELinux.

Easier to setup does not seem like good reason for changing kernel,
I'm afraid. Surely selinux can be improved or
userland-educational-selinux created?
								Pavel
-- 
Thanks, Sharp!

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On Wed, 19 Apr 2006 10:16:46 +0200, Jan Engelhardt said:

> >So, I think the only way to be able to realisticly keep the LSM
> >interface, is for a valid, working, maintained LSM-based security model
> >to go into the kernel tree.  So far, I haven't seen any public posting
> >of patches that meet this requirement :(
> 
> In that case, maybe it would be worthwhile to flip the positions, i.e. LSM on
> top of SELinux, sort of a compat layer.

How would that *possibly* work?  What semantics would *that* have?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Chris Wright]

* James Morris (jmorris@namei.org) wrote:
> How about enough time to get us to 2.6.18, say, two months?

Based on the discussions we had last year, I think the fair date would
be August not June.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-17 at 13:20 -0700, Chris Wright wrote:
> * James Morris (jmorris@namei.org) wrote:
> > How about enough time to get us to 2.6.18, say, two months?
> 
> Based on the discussions we had last year, I think the fair date would
> be August not June.

why?
this is already a year notice...
lets get it over with.. notice goes in now
removal to -mm, goes into 2.6.18

as it is its one helluva hook for the rootkit guys with only pain on the
kernel side (eg selinux) because of the super abstraction.

Re: Time to remove LSM

[David S. Miller]

From: Arjan van de Ven <arjan@infradead.org>
Date: Mon, 17 Apr 2006 22:24:53 +0200

> On Mon, 2006-04-17 at 13:20 -0700, Chris Wright wrote:
> > * James Morris (jmorris@namei.org) wrote:
> > > How about enough time to get us to 2.6.18, say, two months?
> > 
> > Based on the discussions we had last year, I think the fair date would
> > be August not June.
> 
> why?
> this is already a year notice...
> lets get it over with.. notice goes in now
> removal to -mm, goes into 2.6.18

I totally agree, let's get rid of it in 2.6.18, it serves no
real purpose.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Chris Wright]

* Arjan van de Ven (arjan@infradead.org) wrote:
> On Mon, 2006-04-17 at 13:20 -0700, Chris Wright wrote:
> > * James Morris (jmorris@namei.org) wrote:
> > > How about enough time to get us to 2.6.18, say, two months?
> > 
> > Based on the discussions we had last year, I think the fair date would
> > be August not June.
> 
> why?
> this is already a year notice...
> lets get it over with.. notice goes in now
> removal to -mm, goes into 2.6.18

Because the discussion we had at OLS last year (late July) was if there
are no users in one year, it is gone.

> as it is its one helluva hook for the rootkit guys with only pain on the
> kernel side (eg selinux) because of the super abstraction.

The rootkit argument is not that compelling.  Lack of users certainly is.

thanks,
-chris

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Greg KH]

On Mon, Apr 17, 2006 at 01:27:51PM -0700, Chris Wright wrote:
> * Arjan van de Ven (arjan@infradead.org) wrote:
> > On Mon, 2006-04-17 at 13:20 -0700, Chris Wright wrote:
> > > * James Morris (jmorris@namei.org) wrote:
> > > > How about enough time to get us to 2.6.18, say, two months?
> > > 
> > > Based on the discussions we had last year, I think the fair date would
> > > be August not June.
> > 
> > why?
> > this is already a year notice...
> > lets get it over with.. notice goes in now
> > removal to -mm, goes into 2.6.18
> 
> Because the discussion we had at OLS last year (late July) was if there
> are no users in one year, it is gone.

Fair enough, I can't object to this.

And please, do not think that the little "rootplug" example is a real
user, it's an example only.

thanks,

greg k-h

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Chris Wright]

* Greg KH (greg@kroah.com) wrote:
> And please, do not think that the little "rootplug" example is a real
> user, it's an example only.

Yup, agreed.
-chris

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-17 at 13:34 -0700, Greg KH wrote:
> On Mon, Apr 17, 2006 at 01:27:51PM -0700, Chris Wright wrote:
> > * Arjan van de Ven (arjan@infradead.org) wrote:
> > > On Mon, 2006-04-17 at 13:20 -0700, Chris Wright wrote:
> > > > * James Morris (jmorris@namei.org) wrote:
> > > > > How about enough time to get us to 2.6.18, say, two months?
> > > > 
> > > > Based on the discussions we had last year, I think the fair date would
> > > > be August not June.
> > > 
> > > why?
> > > this is already a year notice...
> > > lets get it over with.. notice goes in now
> > > removal to -mm, goes into 2.6.18
> > 
> > Because the discussion we had at OLS last year (late July) was if there
> > are no users in one year, it is gone.
> 
> Fair enough, I can't object to this.

I still think at least in -mm the patch to remove it should go in early,
just to make sure it'll be a smooth transition.

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Chris Wright]

* Arjan van de Ven (arjan@infradead.org) wrote:
> I still think at least in -mm the patch to remove it should go in early,
> just to make sure it'll be a smooth transition.

Sure

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[alan]

On Mon, 17 Apr 2006, Chris Wright wrote:

> * James Morris (jmorris@namei.org) wrote:
>> How about enough time to get us to 2.6.18, say, two months?
>
> Based on the discussions we had last year, I think the fair date would
> be August not June.

September 19th would be even more appropreate.

-- 
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Chris Wright]

* Emily Ratliff (ejratl@gmail.com) wrote:
> On 4/17/06, Chris Wright <chrisw@sous-sol.org> wrote:> Based on the
> discussions we had last year, I think the fair date would
> > be August not June.
> Was the one year deadline announced on LKML or the security module mailing
> list or anywhere that someone who did not attend OLS might have had an
> opportunity to hear about it? In searching the archives, I can't find this
> announcement.

I thought there was something written about it, but I can't find it now.

thanks,
-chris

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-17 at 15:07 -0700, Chris Wright wrote:
> * Emily Ratliff (ejratl@gmail.com) wrote:
> > On 4/17/06, Chris Wright <chrisw@sous-sol.org> wrote:> Based on the
> > discussions we had last year, I think the fair date would
> > > be August not June.
> > Was the one year deadline announced on LKML or the security module mailing
> > list or anywhere that someone who did not attend OLS might have had an
> > opportunity to hear about it? In searching the archives, I can't find this
> > announcement.
> 
> I thought there was something written about it, but I can't find it now.

jamesm posted the LSM mailings he did about this...
which were from may 2005

Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Adrian Bunk]

On Mon, Apr 17, 2006 at 03:20:55PM -0400, James Morris wrote:
>...
> How about enough time to get us to 2.6.18, say, two months?
> 
> 
> Signed-off-by: James Morris <jmorris@namei.org>
> 
> --- linux-2.6.17-rc1.o/Documentation/feature-removal-schedule.txt	2006-04-15 19:57:53.000000000 -0400
> +++ linux-2.6.17-rc1.x/Documentation/feature-removal-schedule.txt	2006-04-17 15:18:15.000000000 -0400
> @@ -246,3 +246,27 @@ Why:	The interface no longer has any cal
>  Who:	Nick Piggin <npiggin@suse.de>
>  
>  ---------------------------
> +
> +What:	LSM (Linux Security Modules) including BSD Secure Levels.
> +When:	June 2006
>...

Why not directly writing the intention?

  When: before 2.6.18

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[David S. Miller]

From: Christoph Hellwig <hch@infradead.org>
Date: Mon, 17 Apr 2006 18:33:19 +0100

> On Mon, Apr 17, 2006 at 01:03:24PM -0400, Stephen Smalley wrote:
> > > fact for access control purposes is fundamentally flawed.  We're not going
> > > to add helpers or exports for it, I'd rather remove the ability to build
> > > lsm hook clients modular completely.
> > 
> > Or, better, remove LSM itself ;)
> 
> Seriously that makes a lot of sense.  All other modules people have come up
> with over the last years are irrelevant and/or broken by design.

I totally agree, let's get rid of LSM while we can.

Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Török Edwin]

On Monday 17 April 2006 19:06, Stephen Smalley wrote:
> On Fri, 2006-04-14 at 23:01 +0300, Török Edwin wrote:
> > Would there be a reason to implement floating labels in SELinux?
>
> Unclear.  CMWs and the Posix.1e draft had floating information labels,
> but they were separate from the access control label.  So if implemented
> in SELinux, they would be a separate field of the incore security
> structures and, if required to persist, they would be a separate xattr
> name/value pair.  They wouldn't be used for access control checking by
> SELinux internally.  One would have to define the meaning of floating
> for TE (or your scheme), as they aren't hierarchical. 
> Traditional 
> hierarchical floating labels track reads and writes, e.g. process
> information label floats up upon reads to dominate the information label
> of the object, and the object information label floats up upon writes to
> dominate the information label of the writing process, so that if P 
> copies from object A to object B, object B ends up with an information
> label at least as high as object A.  Whether or not this is useful has
> been a subject of debate.
I'll have to read more on this, I'll come back later with an answer to this.
>
> > How can I substitute floating labels (i.e. what would be its closest
> > approximation)?
>
> Ideally, you would just predefine your control requirements, as below,
> and enforce that via SELinux policy rather than trying to separately
> track the data flow via LSM and enforce some kind of restriction via
> your userspace component+netfilter module.  

On a second thought a fireflier LSM wasn't such a good idea after all. 
One reason for the kernelspace+userspace mix was that to allow interactivity, 
i.e. ask the user about a packet that would get denied per current policy, 
and if the user so wishes, he can create a new rule on the fly. Doing this 
with selinux isn't possible. But using the security marking, that in my POV 
combines selinux, and iptables, will allow me to ask these kinds of questions 
(by using a nfqueue target). See below for more details.

> Also see the Security 
> marking RFC posted by James Morris to netdev.
 Thanks a lot for telling me about it, this is exactly what I need (I wasn't 
subscribed to netdev, now I am :D)


>
> > Functional requirement:
> <snip>
>
> Hmmm...well, the control requirements above can be met by SELinux, just
> not in the manner you are trying to meet them, as SELinux already labels
> and controls use of sockets and access to ports, nodes (hosts), and
> network interfaces.
Hmmm
>
> > -- plan for fireflier SELinux integration (fireflier target version
> > 2.1)---
> >
> > Possible approaches I thought of:
> > 1)  put programs needing to share a socket in the same domain, and match
> > based on the domain of the socket. But what happens if a program would
> > need to be in 2  or more domains (xinetd comes to mind)
>
> The processes don't have to be in the same domain to share the socket;
> SELinux policy already allows you to permit one domain to
> inherit/receive and use sockets created by another domain if so
> configured.
I'll try to keep this in mind when writing a policy.
>
> > But a problem remains: if there is a base policy that sets a context on a
> > program, and  my module would try to set a domain for it too, won't they
> > conflict?
>
> You could extend the definition of the existing domain via your module
> if that fits your needs.  
I didn't know this is possible , how do I extend its definition?
> As the base policy becomes more modularized, 
> you could replace the particular module entirely with your own if that
> is necessary.
Ok.
>
> > 2) each program has its own domain, and xinetd is in a domain of its own,
> > but it has access to all the sockets of its childs (domains). The same
> > for postfix
> > Also run selinux in non-enforcing mode, with avc logging turned off. I
> > only need labeling, not restrictions.
>
> But you do need restrictions (on network access); you just want to
> implement them yourself for some reason rather than using the existing
> SELinux controls.  Not clear why.
Reason: selinux applies the policy immediately, you can't "queue" them for 
userspace. In iptables you can queue packets for userspace decisions.
Of course, on a server, or a secured desktop such on-the-fly changes are not 
good, but when setting up a the rules (policy) they _are_ usefull.

------------------ New fireflier plans -----------------
Using the security mark interactivity can still be achieved:
- add iptables secmark rules
- add at the end a queue target

Now, when a packet comes, and matches a secmark rule, it gets marked (and 
accepted as far as netfilter is concerned?), and SELinux will take care of 
allow/deny based on policy. This policy can be generated by fireflier.

If no secmark rule (and no "ordinary" iptables rule) matches, the packet will 
arrive at the queue target, and fireflier userspace will ask the user what he 
wants to do. If he wants to create a rule, a new iptables  secmark rule is 
inserted, and an selinux policy generated if needed. 

So "on-the-fly" policy generation is still possible.

Possible issues:
- program gains access to socket, after rule was created, and selinux rules 
deny access => program gets access denied, without user being asked
- program A uses port X, later B uses port X and gets access denied

Fireflier could also watch avc access denied logs, and ask the user if he 
wants to adjust the rules. 

In this case the user doesn't get the opportunity to create a rule "just 
before" the packet would get denied, but this is not such a big problem. The 
packet might be old/timed out already; and besides the program should try 
again if packets don't go through.
Maybe if a packet gets denied due to SELinux policy, it could be reinserted in 
the netfilter chain? Would writing such a policy make sense? 

Something like this (I know this isn't correct selinux syntax):
allow httpd_t http_packet_t:packet { recv }
reinject !httpd_t http_packet_t:packet { recv }
or:
allow httpd_t http_packet_t:packet { recv }
reinject notmachted http_packet_t:packet { recv }
; where notmactced would get applied, if no other domain matched; and reinject 
means to reinject in netfilter chain

--------------------------------------------------------------------------------

>
><snip>
> > - if selinux is enabled, fireflier won't do shared socket checks,
> > assuming that the policy will limit the sharing of sockets
>
> Depends on whether you want your tool to continue to be useful for
> systems using SELinux.
Yes. But I don't want to _require_ the user to have selinux set up.
I am willing to accept for fireflier a  _require selinux support in kernel_, 
and the requirement for a minimal policy for networking only (generated by 
fireflier).
>
> > Important question: can a file's context be set from the policy?
> > (without using setfiles, to relabel the file, the user might want to
> > enable selinux later, I don't want to mess up his labeling)
> > (this might sound silly: can a define a default auto-transition to a
> > context?)
>
> Certain defaults are provided from policy, but the per-file labeling
> comes from the xattrs.  Newly created files are assigned an initial
> label by the kernel (both incore and xattr) based on policy by default,
Good, so I can control the default label.
> or optionally overridden by application request (still subject to policy
> control).
>
> > To have all tasks assigned a security structure, fireflier lsm needs to
> > be compiled into the kernel.
>
> Yes.  So?
That needs patching the kernel, something I wanted to avoid. If I wanted to 
patch the kernel, I would have used the skfilter patches, and there would 
have been no need for fireflier lsm.
>
> > I thought of this, see label_all_processes. Unfortunately I found no way
> > of actually doing this. I would need to iterate through the tasklist
> > structure, but the task_lock export is going to be removed from the
> > kernel.
>
> So, if built-in isn't an option, propose an interface to the core
> security framework to allow security modules to perform such
> initialization without needing to directly touch the lock themselves
> (i.e. they just call the function provided by the security framework,
> and let it deal with taking the lock if that is appropriate).  Not the
> same as exporting the lock directly to all modules for arbitrary misuse.
I'd rather not propose that.
>
> > Locking added. I use a lock every time the inode's sid is modified.
>
> Except that your lock does no good.  See below.
Should have done that spin_lock  earlier, before compute_sid, but I got a
"sleeping function called in atomic context" warning, because I used debugfs 
inside compute_inode_sid. Ok that debugfs would have been removed anyway, so 
I should move the lock earlier.

Doesn't matter anymore, as I found an alternative to fireflier LSM. So 
fireflier LSM is likely to be dropped soon.


Thanks a lot for the comments, ideas you provided, I won't bother you with 
fireflier LSM anymore.

If I have further questions/comments about security mark, selinux+secmark, or 
I need some features in secmark, or I have a patch for secmark,selinux - is 
it ok if I use the Cc: of this mail? (besides linux-security-module)

Thank you again for the feedback provided,

Cheers,
Edwin

Labeling only policy and problems with booleans

[Török Edwin]

Hi,

I am trying to write a policy that does only labeling.
I am asking for your opinion(s) before developing any further.

In particular I'm interesting in having sockets created by a process labeled 
with that process's type. This is by default I assume.

Furthermore I want to do this:
- The process's type shall be determined by the security context of the 
program
- launching the program should be possible from anywhere (by any other 
program)

I started my policy based on the reference policy.
So here it is the policy module:
----------
policy_module(test_module,1.0)
type myapp_exec_t;
gen_require(`
             type unlabeled_t;
        ')
files_type(myapp_exec_t)
domain_type(myapp_t)
unconfined_domain(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t)
domain_auto_trans(unlabeled_t,myapp_exec_t,myapp_t)
domain_auto_trans(unconfined_t,myapp_exec_t,myapp_t)
domain_auto_trans(initrc_t,myapp_exec_t,myapp_t)
libs_use_ld_so(myapp_t)
libs_use_shared_libs(myapp_t)
role system_r types myapp_t;
role user_r types myapp_t;
-------------
I then label the program with myapp_exec_t.
Good, now I want to restrict his:
- There should be no way for a process to set its security context, 
- policy loading and relabeling should be restricted to a single domain. 
- If one enters enforcing mode, there should be no way back

So I remove the selinux_unconfined from unconfined_t, and I set the
secure_mode_policyload at runtime.
Here I got into a problem. Although I set the secure_mode (all 3 of them) to 
1, and verified that they are indeed set via /selinux/booleans, 
I still could load policy. I even got avc granted messages.

This shouldn't be happening. I examined the generated base.conf manually, but 
the only place where load_policy was allowed 
was 'if(!secure_mode_policyload)'. I commented those lines out, rebuilt the 
policy, and now I couldn't load a policy anymore. Ok this is what I wanted. 

But why didn't the booleans work? I tried setting their default values in 
booleans.conf to true, and still the same result, they weren'
t taken into consideration.

(btw, I also ran into a make bug: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358903, I hope this booleans 
problems isn't another build-tool related bug, if needed I can make the 
compiled policy module available for analysis)

I'll now describe my goals and motivation.
The goal is to have sockets labeled with a security context, so that I can use 
skfilter context matches in iptables to filter packets based on selinux 
security context.

I want to fireflier to work both with selinux enabled distros 
(fc5,gentoo-selinux), and those that aren't by default selinux enabled 
(debian,gentoo...).

So fireflier shall have 2 modes of operation (determined at runtime which to 
use).

Mode 1: for systems that don't have an selinux policy (yet) , but have selinux 
enabled in kernel.

Provide a base module built from the reference policy: base.pp, with the 
following modifications:
- unconfined_t domains aren't allowed to load policy
- policy load, and enforcing mode can only be done by semanage_exec_t
- transitions to (executing) semanage_exec_t|semanage_t can be done only from 
fireflier_t
- unconfined_t is allowed to execute fireflier_exec_t
- Make all programs unconfined by default
- Make the default label be default_t, or unconfined_t
- have as little performance hit on the system as possible (by removing 
unneeded types/rules)

I think the target policy is the best policy to start. 
When a new type is needed (to be used for iptables match), fireflier creates a 
new policy module for it:
----------
policy_module(new_module,1.0)
type myapp_exec_t;
gen_require(`
             type unlabeled_t;
        ')
files_type(myapp_exec_t)
domain_type(myapp_t)
unconfined_domain(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t)
domain_auto_trans(unlabeled_t,myapp_exec_t,myapp_t)
domain_auto_trans(unconfined_t,myapp_exec_t,myapp_t)
can_exec(unconfined_t,myapp_exec_t)
can_exec(myapp_t,unconfined_exec_t)
can_exec(myapp_t,unlabeled_t)
role system_r types myapp_t;
role user_r types myapp_t;
---------

I also thought of having an attribute fireflier_generated, and then create a 
single rule to allow unconfined_t transition to fireflier_generated types, 
and fireflier_generated_types -> unconfined_t. Would this be faster?

Also since all programs will have unlabeled_t by default, there is no point to 
do an initial relabeling, so either:
 - mount -o context=unconfined_t
 - do nothing, and the programs will get by default unlabeled_t, or file_t, 
right?

Of course, the programs that rules are created for will get relabeled.
I am also thinking of letting the user customize the generated policy later.

Any security problems with the approach I used?

One of the other goals is the ability to be able to boot the system in 
enforcing mode, without any manual policy modifications. If all programs are 
unconfined_t/default_t will this be possible?

I also thought of creating an even more minimal base policy, but I am not sure 
what I should remove from there, without breaking anything (I've seen class, 
inherit, constrain, sid, portcon, fs_xattr,... I think these are critical for 
selinux policy work, aren't they?) Would a more minimal policy make selinux 
work faster?

Mode 2: The user already has a selinux policy

When the user wants to creat a rule for a packet, fireflier will ask if using 
the existinig domain of the program is ok (for example: the packet would be 
received by httpd_t: create a rule to allow httpd_t to receive packets on 
port 80?).
1) If the user wants to use existing domain: create iptables rule for it, and 
we are done. But all programs having that domain will have access to the 
network, which can  be a problem if they are in the user's home directory 
(user_home_t) for example.
2) If the user want only this program to have access:
- create a new domain that is equivalent to the old domain, except:
 - it is called myapp_t (of course myapp will be unique to each program)
 - it creates sockets labeled myapp_t
 - only types having the attribute myapp_sock_access will have access to the 
socket (of course myapp_t will have that attribute)
 The rest of the files created by myapp_t have the same label (or equivalent) 
as the files created if it would have the old domain
 - it has all the rights the old domain had (as long as they don't conflict 
with the ones above)

There might be one problem with "giving access only to myapp_t to its 
sockets", this might break some programs (postfix, xinetd, etc.).

Since all the programs that need access to the socket are running already (we 
are generating policies on-the-fly), we can ask the user which programs he 
wants to give access to the socket, and create a policy for that. Maybe 
creating an attribute, and applying that attribute to those programs' types, 
and create a "neverallow ~myattribute" rule for the socket access.

(Since we want  to make rules for individual programs, new types will be 
created for each program needing access to the socket, see above, and those 
new types will get the myattribute attribute; note- myattribute will be 
unique to each "rule": myattribute1, myattribute2,... or something like that)



The big issue here is creating a domain that is equivalent, because AFAIK 
there is no inheritance for types in selinux (there is inheritance for 
classes though right?).
So one possible way of doing this would be using the tool sesearch to search 
for all the transitions/allow/dontallow rules, and then do a replace of old 
type with new type, watching out for this: not giving access to the socket to 
other programs.
Is there any other way of creating an equivalent type? (I want to create an 
equivalent type, because I dont' want to change the user's policy much, I 
only want the sockets to have a different label, for the purpose of iptables 
match; as far as the selinux rules are concerned they should be identical to 
the old type).


Of course in both mode 1, and mode 2 the program will be relabeled by 
fireflier to the new type.

Are there any fundamental problems with automated policy generation like this, 
is there anything I should watch out for?

In both modes it is important to not allow arbitrary policy reload, and 
relabeling, and setcontexts. Anything else I should watch our for? 
I only want the programs I label to have their sockets labeled with that 
context.


Finally, solving the shared socket issue:

  - it will allow access to the socket for only the programs allowed by its 
policy, if a new program wants access, the user is asked, and granted his 
permission, we create an allow rule (for that socket to be accessed by that 
other program)



 

 On Monday 17 April 2006 19:06, Stephen Smalley wrote:
 > On Fri, 2006-04-14 at 23:01 +0300, Török Edwin wrote:
 > > Would there be a reason to implement floating labels in SELinux?
 >
 > Unclear.  CMWs and the Posix.1e draft had floating information labels,
 > but they were separate from the access control label.  So if implemented
 > in SELinux, they would be a separate field of the incore security
 > structures and, if required to persist, they would be a separate xattr
 > name/value pair.  They wouldn't be used for access control checking by
 > SELinux internally.  One would have to define the meaning of floating
 > for TE (or your scheme), as they aren't hierarchical.
 > Traditional
 > hierarchical floating labels track reads and writes, e.g. process
 > information label floats up upon reads to dominate the information label
 > of the object, and the object information label floats up upon writes to
 > dominate the information label of the writing process, so that if P
 > copies from object A to object B, object B ends up with an information
 > label at least as high as object A.  Whether or not this is useful has
 > been a subject of debate.
I think floating labels aren't what I want after all. Tracking when floating 
happens is complicated (for me at least), and would make writing a correct 
policy harder.
( Can't something similar be done already with MCS/MLS? Anyway MLS/MCS is  not 
what fireflier wants to do.)


P.S.: Please point out any security holes my approach might introduce, and if 
there are better ways to achieve what I want.

Cheers,
Edwin

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Stephen Smalley]

On Sun, 2006-04-23 at 22:58 +0300, Török Edwin wrote:
> I am trying to write a policy that does only labeling.
> I am asking for your opinion(s) before developing any further.
> 
> In particular I'm interesting in having sockets created by a process labeled 
> with that process's type. This is by default I assume.

Yes.

> Furthermore I want to do this:
> - The process's type shall be determined by the security context of the 
> program
> - launching the program should be possible from anywhere (by any other 
> program)
> 
> I started my policy based on the reference policy.
> So here it is the policy module:
> ----------
> policy_module(test_module,1.0)
> type myapp_exec_t;
> gen_require(`
>              type unlabeled_t;
>         ')
> files_type(myapp_exec_t)
> domain_type(myapp_t)
> unconfined_domain(myapp_t)
> domain_entry_file(myapp_t, myapp_exec_t)
> domain_auto_trans(unlabeled_t,myapp_exec_t,myapp_t)

No process should be running in unlabeled_t (a process might be
re-mapped to unlabeled_t if its type was removed from policy and policy
was reloaded while the process was still running, but this would quickly
lead to death for the process as it would lose access to its resources).

> domain_auto_trans(unconfined_t,myapp_exec_t,myapp_t)
> domain_auto_trans(initrc_t,myapp_exec_t,myapp_t)

Should be some higher level interface for running a program as a user
app and as a daemon, right?  You don't want to make direct references to
other modules' types if it can be avoided.

> libs_use_ld_so(myapp_t)
> libs_use_shared_libs(myapp_t)
> role system_r types myapp_t;
> role user_r types myapp_t;
> -------------
> I then label the program with myapp_exec_t.
> Good, now I want to restrict his:
> - There should be no way for a process to set its security context, 
> - policy loading and relabeling should be restricted to a single domain. 
> - If one enters enforcing mode, there should be no way back
> 
> So I remove the selinux_unconfined from unconfined_t, and I set the
> secure_mode_policyload at runtime.
> Here I got into a problem. Although I set the secure_mode (all 3 of them) to 
> 1, and verified that they are indeed set via /selinux/booleans, 
> I still could load policy. I even got avc granted messages.
> 
> This shouldn't be happening. I examined the generated base.conf manually, but 
> the only place where load_policy was allowed 
> was 'if(!secure_mode_policyload)'. I commented those lines out, rebuilt the 
> policy, and now I couldn't load a policy anymore. Ok this is what I wanted. 
> 
> But why didn't the booleans work? I tried setting their default values in 
> booleans.conf to true, and still the same result, they weren'
> t taken into consideration.

I think we need more details to see whether this is a bug or not.  What
version of refpolicy?  What version of checkpolicy?  There was a problem
with the boolean mapping at link time with the optionals-in-base changes
to refpolicy and certain versions of checkpolicy, but I think that has
been resolved in the current version (although optionals-in-base still
doesn't work properly, but that doesn't affect you as long as you are
building everything you need into base).

> (btw, I also ran into a make bug: 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358903, I hope this booleans 
> problems isn't another build-tool related bug, if needed I can make the 
> compiled policy module available for analysis)

Yes, that would be helpful.

> I also thought of having an attribute fireflier_generated, and then create a 
> single rule to allow unconfined_t transition to fireflier_generated types, 
> and fireflier_generated_types -> unconfined_t. Would this be faster?

Originally, attributes were all expanded when policy was compiled, and
the kernel just dealt with the individual pairs.  But current kernels
and policies retain attributes in the rules when feasible, so the
representation is more compact if you use attributes in your rules.  So
you save memory that way.  Runtime processing itself is largely
unaffected, as the access vector cache provides most of the security
decisions, so security server computations are infrequent.

> Also since all programs will have unlabeled_t by default, there is no point to 
> do an initial relabeling, so either:
>  - mount -o context=unconfined_t
>  - do nothing, and the programs will get by default unlabeled_t, or file_t, 
> right?

Using unlabeled_t in this way is a bad idea; it is used internally for
various purposes to identity unlabeled entities or entities that have
become unlabeled due to label invalidation.

> One of the other goals is the ability to be able to boot the system in 
> enforcing mode, without any manual policy modifications. If all programs are 
> unconfined_t/default_t will this be possible?

If everything is unconfined, then naturally enforcing mode has no real
impact on behavior.

> I also thought of creating an even more minimal base policy, but I am not sure 
> what I should remove from there, without breaking anything (I've seen class, 
> inherit, constrain, sid, portcon, fs_xattr,... I think these are critical for 
> selinux policy work, aren't they?) Would a more minimal policy make selinux 
> work faster?

The flask definitions (classes, initial SIDs, access vectors) shouldn't
be disturbed, as they are generated into definitions that are built into
the kernel.  The fs_use definitions are fundamental and shouldn't be
modified except possibly to add new ones if appropriate for some
filesystem type that you are using.  Constraints do slow down processing
of the security server computation, but most security decisions are
provided by the AVC after the first such computation, so it isn't really
critical, and the constraints do provide important restrictions.  Object
context definitions like portcon, netifcon, etc. can be omitted if you
aren't truly using the SELinux network access controls.  Primarily, you
just want to minimize the TE rules for memory efficiency.

> Since all the programs that need access to the socket are running already (we 
> are generating policies on-the-fly), we can ask the user which programs he 
> wants to give access to the socket, and create a policy for that. Maybe 
> creating an attribute, and applying that attribute to those programs' types, 
> and create a "neverallow ~myattribute" rule for the socket access.

neverallow rules don't grant access; they just specify invariants that
should be checked when policy is compiled (or in the case of modules,
when policy is linked and expanded to kernel policy).

> The big issue here is creating a domain that is equivalent, because AFAIK 
> there is no inheritance for types in selinux (there is inheritance for 
> classes though right?).

Right, there is no inheritance for types.  Object classes have a
primitive inheritance mechanism for their permission sets, but it is
very limited.

> So one possible way of doing this would be using the tool sesearch to search 
> for all the transitions/allow/dontallow rules, and then do a replace of old 
> type with new type, watching out for this: not giving access to the socket to 
> other programs.
> Is there any other way of creating an equivalent type? (I want to create an 
> equivalent type, because I dont' want to change the user's policy much, I 
> only want the sockets to have a different label, for the purpose of iptables 
> match; as far as the selinux rules are concerned they should be identical to 
> the old type).

Hmmm...there used to be a clone statement in the language, but it was
ultimately dropped because the semantics were ambiguous and what you
usually want is not truly complete equivalence, just structural
parallel.  e.g. for the new type, you don't want to allow it access to
private/derived types of the old type - you want to allow it to access
its own private/derived types.  And you don't necessarily want to allow
the same relationships with ancestors and descendants.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Christopher J. PeBenito]

On Wed, 2006-04-26 at 09:37 -0400, Stephen Smalley wrote:
> On Sun, 2006-04-23 at 22:58 +0300, Török Edwin wrote:
> > domain_auto_trans(unconfined_t,myapp_exec_t,myapp_t)
> > domain_auto_trans(initrc_t,myapp_exec_t,myapp_t)
> 
> Should be some higher level interface for running a program as a user
> app and as a daemon, right?  You don't want to make direct references to
> other modules' types if it can be avoided.

There isn't one currently for unconfined users, but that should be added
for 3rd party use.  There are two potentials for the initrc,
init_daemon_domain() and init_system_domain().  The first one is
(obviously) for daemons, and the second one is for short running
initialization-style processes such as mount and ifconfig; they both
have the same parameters, for example:

init_daemon_domain(myapp_t,myapp_exec_t)

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Török Edwin]

On Wednesday 26 April 2006 17:13, Christopher J. PeBenito wrote:
> On Wed, 2006-04-26 at 09:37 -0400, Stephen Smalley wrote:
> >
> > Should be some higher level interface for running a program as a user
> > app and as a daemon, right?  You don't want to make direct references to
> > other modules' types if it can be avoided.
>
> There isn't one currently for unconfined users, but that should be added
> for 3rd party use. 
What about interface(`unconfined_domain',  (in unconfined.fc)?
> There are two potentials for the initrc, 
> init_daemon_domain() and init_system_domain().  The first one is
> (obviously) for daemons, and the second one is for short running
> initialization-style processes such as mount and ifconfig; they both
> have the same parameters, for example:
>
> init_daemon_domain(myapp_t,myapp_exec_t)
I'll use this one and unconfined_domain.

Is using unconfined_domain enough, or should I also add init_daemon_domain? 
Does init_daemon_domain grant any privileges that unconfined domain doesn't 
have?

I also need to remove the ability to load policy from an unconfined domain 
(see my previous mail), if I remove that from unconfined.te, build a base.pp, 
and distribute that along with fireflier, will that be ok? 
Or will you consider including a boolean to disable policy loading for 
unconfined domains (separate from the boolean that restrict policy loading 
for the kernel), so that I can turn off policy loading for unconfined 
domains, but keep it for "privileged" domains?


Thanks,
Edwin




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Christopher J. PeBenito]

On Wed, 2006-04-26 at 21:18 +0300, Török Edwin wrote:
> On Wednesday 26 April 2006 17:13, Christopher J. PeBenito wrote:
> > On Wed, 2006-04-26 at 09:37 -0400, Stephen Smalley wrote:
> > >
> > > Should be some higher level interface for running a program as a user
> > > app and as a daemon, right?  You don't want to make direct references to
> > > other modules' types if it can be avoided.
> >
> > There isn't one currently for unconfined users, but that should be added
> > for 3rd party use. 
> What about interface(`unconfined_domain',  (in unconfined.fc)?
> > There are two potentials for the initrc, 
> > init_daemon_domain() and init_system_domain().  The first one is
> > (obviously) for daemons, and the second one is for short running
> > initialization-style processes such as mount and ifconfig; they both
> > have the same parameters, for example:
> >
> > init_daemon_domain(myapp_t,myapp_exec_t)
> I'll use this one and unconfined_domain.
> 
> Is using unconfined_domain enough, or should I also add init_daemon_domain? 
> Does init_daemon_domain grant any privileges that unconfined domain doesn't 
> have?

unconfined_domain() only makes the specified domain unconfined, it
doesn't make a transition from unconfined_t to the domain.
init_daemon_domain() makes a transition from initrc_t to the specified
domain.  Perhaps we should consider renaming the interfaces to clear up
this confusion.

> I also need to remove the ability to load policy from an unconfined domain 
> (see my previous mail), if I remove that from unconfined.te, build a base.pp, 
> and distribute that along with fireflier, will that be ok? 

If you want the fierflier policy to replace the distro's policy, that
seems reasonable.

> Or will you consider including a boolean to disable policy loading for 
> unconfined domains (separate from the boolean that restrict policy loading 
> for the kernel), so that I can turn off policy loading for unconfined 
> domains, but keep it for "privileged" domains?

Right now in the upstream policy, unconfined_domain() means fully
unconfined.  It might be more acceptable if we do a labeled boolean so
only access to that boolean is disabled when secure mode is enabled,
rather than disabling all boolean access.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Török Edwin]

On Wednesday 26 April 2006 16:37, Stephen Smalley wrote:
> On Sun, 2006-04-23 at 22:58 +0300, Török Edwin wrote:
> > domain_auto_trans(unlabeled_t,myapp_exec_t,myapp_t)
>
> No process should be running in unlabeled_t (a process might be
> re-mapped to unlabeled_t if its type was removed from policy and policy
> was reloaded while the process was still running, but this would quickly
> lead to death for the process as it would lose access to its resources).
Ok, I won't add rules for unlabeled_t.
> > But why didn't the booleans work? I tried setting their default values in
> > booleans.conf to true, and still the same result, they weren'
> > t taken into consideration.
>
> I think we need more details to see whether this is a bug or not.
> What 
> version of refpolicy?
20060307
> What version of checkpolicy?
checkpolicy 1.30-1, runnning on AMD64, kernel 2.6.16, debian sid.
I also tried:checkpolicy-1.30.3-1.fc5 on fedora core 5.
The virtual machine I tested my policy is emulating an x86_64 too.
I tried loading the policies generated by both versions, and I had 
the "boolean problem" with both.
> There was a problem  
> with the boolean mapping at link time with the optionals-in-base changes
> to refpolicy and certain versions of checkpolicy, but I think that has
> been resolved in the current version (although optionals-in-base still
> doesn't work properly, but that doesn't affect you as long as you are
> building everything you need into base).
If I have only the base module loaded (and anything else besides 
unconfined.pp) then setting secure_mode_policyload works as expected. However 
if I load unconfined.pp, I can change the policy even after 
secure_mode_policyload 
As soon as I remove unconfined.pp (and its dependencies), 
secure_mode_policyload works again.
>
> > (btw, I also ran into a make bug:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358903, I hope this
> > booleans problems isn't another build-tool related bug, if needed I can
> > make the compiled policy module available for analysis)
>
> Yes, that would be helpful.
The policy where I had unconfined linked (boolean not working) 
http://edwintorok.googlepages.com/policybad.tar.gz

The policy where I didn't have unconfined linked: 
http://edwintorok.googlepages.com/policyok.tar.gz

kernel messages: http://edwintorok.googlepages.com/messages
full build directory: http://edwintorok.googlepages.com/refpolicy.tgz

Let me know if anything else is needed to trace the problem.

There is another thing that worries me.
I was able to do mknod xx c 1 2  creating an equivalent of /dev/kmem, and it 
wasn't labeled memory_device_t, it was labeled unlabeled_t.
So I guess giving access to unlabeled_t files is very dangerous (as you say 
below). I assume one could exploit this by writing a program that creates a 
kmem equivalent, and then he can do anything he wishes, including replacing 
policy, loading another kernel module, patch syscalls...., am I right?

>
> Originally, attributes were all expanded when policy was compiled, and
> the kernel just dealt with the individual pairs.  But current kernels
> and policies retain attributes in the rules when feasible, so the
> representation is more compact if you use attributes in your rules.  So
> you save memory that way.  Runtime processing itself is largely
> unaffected, as the access vector cache provides most of the security
> decisions, so security server computations are infrequent.
So I shouldn't worry about the number of types/attributes in my policy as far 
as performance is concerned. I might optimize when the policy is final, to 
save some memory.
>
> > Also since all programs will have unlabeled_t by default, there is no
> > point to do an initial relabeling, so either:
> >  - mount -o context=unconfined_t
> >  - do nothing, and the programs will get by default unlabeled_t, or
> > file_t, right?
>
> Using unlabeled_t in this way is a bad idea; it is used internally for
> various purposes to identity unlabeled entities or entities that have
> become unlabeled due to label invalidation.
I'll avoid using unlabeled_t.


What is the best practice to do when: most of the programs  on the system will 
run as unconfined_t, so they'll all have the same (default) label (on my 
system file_t seems to be the default label) except:
 - devices in /dev (handled by udev policy?)
 - selinux policy loading programs (loadpolicy, semodule)
But I do want to be able to label individual files (when fireflier generates 
policies for them).

If I don't run setfiles, and I run restorecon only for the: selinux policy 
loading programs, and fireflier, will that be safe? (will an unlabeled 
program be able to gain access to another domain besides unconfined_t)
Also, should I consider doing the policy loading myself in fireflier (via 
libselinux,libsemanage...) instead of relying on an external program?

>
> > One of the other goals is the ability to be able to boot the system in
> > enforcing mode, without any manual policy modifications. If all programs
> > are unconfined_t/default_t will this be possible?
>
> If everything is unconfined, then naturally enforcing mode has no real
> impact on behavior.
Ok. But let me clarify, by unconfined_t I don't mean unconfined_t from the 
targeted policy, since that has policy loading allowed. 
I want to allow unconfined_t everything except:
 - loading policy
 - changing labels
 - kernel module loading (boolean controlled, if I get booleans working)
 - changing iptables rules
 - writing to raw memory
Fireflier doesn't aim to be a full security solution, I just want it to create 
proper labels for skfilter to use, and as such there should be no way for an 
unconfined_t process to change labels/load policy. 

I however don't care (maybe in a future version of fireflier I will) if an 
unconfined_t writes to raw disk devices for example, etc.  as long as it 
doesn't "escape" the packet filtering rules.

I could have just created a policy that imposes no restrictions (like 
secure_mode_policyload, protection from raw memory writes, protection from 
security context transitions), since a program that is able to do that is 
root, and if he is root he could just 'iptables -F', and all is over.
But I considered to provide some of the protections of the targeted policy, 
since if people see fireflier creates&uses selinux policies,
will think "ah it uses selinux, this must be safe, so if I put this iptables 
rule here it will make sure that only this program is allowed to receive on 
that port. Not even if somebody gains root, will he be able to alter my 
iptables rules". I'll document clearly that fireflier doesn't aim at 
protecting you from root exploits, and the actions of root; but I think that 
offering "some" protection against root is better, than none at all.


>
> > I also thought of creating an even more minimal base policy, but I am not
> > sure what I should remove from there, without breaking anything (I've
> > seen class, inherit, constrain, sid, portcon, fs_xattr,... I think these
> > are critical for selinux policy work, aren't they?) Would a more minimal
> > policy make selinux work faster?
>
> The flask definitions (classes, initial SIDs, access vectors) shouldn't
> be disturbed, as they are generated into definitions that are built into
> the kernel.  The fs_use definitions are fundamental and shouldn't be
> modified except possibly to add new ones if appropriate for some
> filesystem type that you are using. 
I won't touch them.
> Constraints do slow down processing 
> of the security server computation, but most security decisions are
> provided by the AVC after the first such computation, so it isn't really
> critical, and the constraints do provide important restrictions.  
So I'll leave these ones alone too.
> Object 
> context definitions like portcon, netifcon, etc. can be omitted if you
> aren't truly using the SELinux network access controls.  Primarily, you
> just want to minimize the TE rules for memory efficiency.
Ok, I'll do this as a final optimization step.
>
> > Since all the programs that need access to the socket are running already
> > (we are generating policies on-the-fly), we can ask the user which
> > programs he wants to give access to the socket, and create a policy for
> > that. Maybe creating an attribute, and applying that attribute to those
> > programs' types, and create a "neverallow ~myattribute" rule for the
> > socket access.
>
> neverallow rules don't grant access; they just specify invariants that
> should be checked when policy is compiled (or in the case of modules,
> when policy is linked and expanded to kernel policy).
I intend to use neverallow to catch policy generation bugs, and ...policy 
creating logic errors. Also will it stop somebody from loading  a policy 
module that overrides my restrictions?

>
>
> Hmmm...there used to be a clone statement in the language, but it was
> ultimately dropped because the semantics were ambiguous and what you
> usually want is not truly complete equivalence, just structural
> parallel.  e.g. for the new type, you don't want to allow it access to
> private/derived types of the old type - you want to allow it to access
> its own private/derived types.  And you don't necessarily want to allow
> the same relationships with ancestors and descendants.
Consider this scenario:
 - there is a type: original_exec_t, that transitions to original_t domain; 
and 10 programs are labeled with it
 - files created by original_t can be written by another_t
 - I want to create a rule for only 2 programs out of those, so I create a new 
type: sub_original_exec_t, sub_original_t and apply this label to these 2 
programs. (and I'll create skfilter rules for these labels).
I want to keep the allowed interactions between the 10 programs in original_t, 
so I'll have to give programs that are now sub_original_t, the same right 
they would have had if they stayed original_t. And I also want to be give 
another_t write access to files created by sub_original_t (creating files 
that have the same label as original_t would have gave them should he 
enough?)

Is this what you referred to as structural equivalence?

But you are right, if somebody creates descendant types he has to consider 
which type he actually wants original_t, or sub_original_t .

How can I create a type that is structurally equivalent? (read all rules 
associated with that type from the binary policy, and generate 
allow/transition/etc. rules based on them?)


Thanks in advance,
Edwin 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Stephen Smalley]

On Wed, 2006-04-26 at 21:13 +0300, Török Edwin wrote:
> The policy where I had unconfined linked (boolean not working) 
> http://edwintorok.googlepages.com/policybad.tar.gz
> 
> The policy where I didn't have unconfined linked: 
> http://edwintorok.googlepages.com/policyok.tar.gz

sediff of these two policies shows a _lot_ of differences, including 107
added types in the "bad" policy.  Are you sure they are identical except
for linking unconfined?  What is in that module (source)?

I do see an allow unconfined_t security_t:security load_policy under a
different boolean in the "bad" policy; looks like a boolean mapping
problem at link time.  We did see those when the optionals-in-base
support was first merged, so the Debian checkpolicy might have an issue
there, but that should have been resolved in 1.30.3 or newer, built
against libsepol 1.12.3 or newer.

> kernel messages: http://edwintorok.googlepages.com/messages
> full build directory: http://edwintorok.googlepages.com/refpolicy.tgz

This one returned a 404 error.

> Let me know if anything else is needed to trace the problem.
> 
> There is another thing that worries me.
> I was able to do mknod xx c 1 2  creating an equivalent of /dev/kmem, and it 
> wasn't labeled memory_device_t, it was labeled unlabeled_t.
> So I guess giving access to unlabeled_t files is very dangerous (as you say 
> below). I assume one could exploit this by writing a program that creates a 
> kmem equivalent, and then he can do anything he wishes, including replacing 
> policy, loading another kernel module, patch syscalls...., am I right?

Not entirely.  Keep in mind that opening the memory devices requires
CAP_SYS_RAWIO, so you also need the SELinux sys_rawio permission in the
capability class to make use of such a device node even if you can
create one.  However, ensuring a consistent label on devices
irrespective of filesystem node used to access them would be nice; there
has been some consideration of labeling the internal objects rather than
just the filesystem nodes and applying access control at that layer to
ensure consistent control.  In the meantime, be careful about who you
allow to create device nodes and who you allow sys_rawio in your policy.

> What is the best practice to do when: most of the programs  on the system will 
> run as unconfined_t, so they'll all have the same (default) label (on my 
> system file_t seems to be the default label) except:

If you don't assign an xattr, then SELinux uses the context associated
with the 'file' initial SID in initial_sid_contexts as the default label
for the file.

>  - devices in /dev (handled by udev policy?)
>  - selinux policy loading programs (loadpolicy, semodule)
> But I do want to be able to label individual files (when fireflier generates 
> policies for them).
> 
> If I don't run setfiles, and I run restorecon only for the: selinux policy 
> loading programs, and fireflier, will that be safe? (will an unlabeled 
> program be able to gain access to another domain besides unconfined_t)
> Also, should I consider doing the policy loading myself in fireflier (via 
> libselinux,libsemanage...) instead of relying on an external program?

Normative pattern is to install policy modules via semodule, which calls
libsemanage to perform the actual installation and loading of policy.
libsemanage uses the external programs as appropriate.  Then you just
have to invoke restorecon as appropriate to label the desired files.
Using the external program is preferred, and may be enforced via policy
under some policies.

> Ok. But let me clarify, by unconfined_t I don't mean unconfined_t from the 
> targeted policy, since that has policy loading allowed. 
> I want to allow unconfined_t everything except:
>  - loading policy
>  - changing labels
>  - kernel module loading (boolean controlled, if I get booleans working)
>  - changing iptables rules
>  - writing to raw memory
> Fireflier doesn't aim to be a full security solution, I just want it to create 
> proper labels for skfilter to use, and as such there should be no way for an 
> unconfined_t process to change labels/load policy. 

I'm not certain how useful this is, as there are obvious bypasses here
unless you start dealing with all of the dependencies for the associated
programs and their data, e.g. can unconfined_t still update glibc?  At
which point unconfined_t becomes a misnomer and you start approximating
the strict policy more and more.

> I intend to use neverallow to catch policy generation bugs, and ...policy 
> creating logic errors. Also will it stop somebody from loading  a policy 
> module that overrides my restrictions?

semodule/libsemanage should end up rejecting a module if it violates a
neverallow rule in the base or any other module, so in one sense, yes.
But keep in mind that if the person loading the policy module has the
ability to manipulate the module store, then they can always
remove/replace the module that has those assertions, so you have to
ensure non-bypassability there.  Ultimately, libsemanage will interface
to a policy management daemon that will enforce such restriction more
strongly, with the policy ensuring that the daemon can't be bypassed to
directly manipulate the store.

> How can I create a type that is structurally equivalent? (read all rules 
> associated with that type from the binary policy, and generate 
> allow/transition/etc. rules based on them?)

Usually we do this by defining interfaces/macros in the policy itself,
and then instantiating multiple types from it.  Rather than trying to
automatically infer it.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Török Edwin]

On Wednesday 26 April 2006 22:26, Stephen Smalley wrote:
>
> sediff of these two policies shows a _lot_ of differences, including 107
> added types in the "bad" policy.  Are you sure they are identical except
> for linking unconfined?  What is in that module (source)?
Hmm, that is *bad*. The module source is in the refpolicy.tgz.
I linked unconfined _and_ all its dependencies (which is quite a lot, from 
memory:
init,udev,userdomain,locallogin,libraries,storage,miscfiles,authlogin,...)
>
> I do see an allow unconfined_t security_t:security load_policy under a
> different boolean in the "bad" policy; looks like a boolean mapping
> problem at link time.  We did see those when the optionals-in-base
> support was first merged, so the Debian checkpolicy might have an issue
> there, but that should have been resolved in 1.30.3 or newer, built
> against libsepol 1.12.3 or newer.
I'll try upgrading libsepol in fc5, and I'll also try to build 
checkpolicy+libsepol manually from the latest sources. I'll let you know 
(possibbly tomorrow) if this makes a difference.
btw, wouldn't it be nice for checkpolicy to have a --version option, currently 
I have to use apt-cache policy for debian, rpm -q for redhat, etc. to find 
out which version I have.
>
> > kernel messages: http://edwintorok.googlepages.com/messages
> > full build directory: http://edwintorok.googlepages.com/refpolicy.tgz
Upload size limit :(, try this one:
http://projects.emerge.upt.ro/Kernel-Dev/browser/fireflier/refpolicy.tgz?format=raw
>
> This one returned a 404 error.
>
> > Let me know if anything else is needed to trace the problem.
> >
> > There is another thing that worries me.
> > I was able to do mknod xx c 1 2  creating an equivalent of /dev/kmem, and
> > it wasn't labeled memory_device_t, it was labeled unlabeled_t.
> > So I guess giving access to unlabeled_t files is very dangerous (as you
> > say below). I assume one could exploit this by writing a program that
> > creates a kmem equivalent, and then he can do anything he wishes,
> > including replacing policy, loading another kernel module, patch
> > syscalls...., am I right?
>
> Not entirely.  Keep in mind that opening the memory devices requires
> CAP_SYS_RAWIO, so you also need the SELinux sys_rawio permission in the
> capability class to make use of such a device node even if you can
> create one.  However, ensuring a consistent label on devices
> irrespective of filesystem node used to access them would be nice; there
> has been some consideration of labeling the internal objects rather than
> just the filesystem nodes and applying access control at that layer to
> ensure consistent control.  
That would be nice. Then device under /dev would automatically get the correct 
label? It would also eliminate a few bootstrapping problems (currently I have 
to reboot using init=/bin/sh, relabel /dev, and then reboot&relabel after 
udev is up).
> In the meantime, be careful about who you 
> allow to create device nodes and who you allow sys_rawio in your policy.
Ok
>
>
> >  - devices in /dev (handled by udev policy?)
> >  - selinux policy loading programs (loadpolicy, semodule)
> > But I do want to be able to label individual files (when fireflier
> > generates policies for them).
> >
> > If I don't run setfiles, and I run restorecon only for the: selinux
> > policy loading programs, and fireflier, will that be safe? (will an
> > unlabeled program be able to gain access to another domain besides
> > unconfined_t) Also, should I consider doing the policy loading myself in
> > fireflier (via libselinux,libsemanage...) instead of relying on an
> > external program?
>
> Normative pattern is to install policy modules via semodule, which calls
> libsemanage to perform the actual installation and loading of policy.
> libsemanage uses the external programs as appropriate.  Then you just
> have to invoke restorecon as appropriate to label the desired files.
> Using the external program is preferred, and may be enforced via policy
> under some policies.
I'll use semodule then. Would it make sense to add file integrity check to 
fireflier (checksum/secure hash/digital signature)? (for checking if semodule 
is actually what it should be)
>
> > Ok. But let me clarify, by unconfined_t I don't mean unconfined_t from
> > the targeted policy, since that has policy loading allowed.
> > I want to allow unconfined_t everything except:
> >  - loading policy
> >  - changing labels
> >  - kernel module loading (boolean controlled, if I get booleans working)
> >  - changing iptables rules
> >  - writing to raw memory
> > Fireflier doesn't aim to be a full security solution, I just want it to
> > create proper labels for skfilter to use, and as such there should be no
> > way for an unconfined_t process to change labels/load policy.
>
> I'm not certain how useful this is, as there are obvious bypasses here
> unless you start dealing with all of the dependencies for the associated
> programs and their data, e.g. can unconfined_t still update glibc?  At
> which point unconfined_t becomes a misnomer and you start approximating
> the strict policy more and more.
Like I said, fireflier is going to deal with the networking part only. I just 
wanted to add some simple protection to prevent simple bypasses. By simple I 
mean those that can be done instantly: if somebody loads a policy it has 
bypassed fireflier. OTOH if he wouldn't have had fireflier installed, 
somebody could have just flushed the iptables rules.
So maybe I'll focus on the networking part, and label transition part only, 
and _not_ think of N possible ways to punch holes in the system, if somebody 
really wants to.

So the only kind of protection that still makes sense, and would be easy to do 
(I hope) is to prevent programs from switching contexts(AFAIK there are some 
libselinux functions, that can be called to do that switch).
>
> > I intend to use neverallow to catch policy generation bugs, and ...policy
> > creating logic errors. Also will it stop somebody from loading  a policy
> > module that overrides my restrictions?
>
> semodule/libsemanage should end up rejecting a module if it violates a
> neverallow rule in the base or any other module, so in one sense, yes.
> But keep in mind that if the person loading the policy module has the
> ability to manipulate the module store, then they can always
> remove/replace the module that has those assertions, so you have to
> ensure non-bypassability there.
I didn't mean to protect against malicious users with neverallow. I only 
wanted to give the user/sysadmin a warning, that he breaks some rules he has 
previously set: so that he doesn't "by accident" invalidate fireflier's 
rules.
> Ultimately, libsemanage will interface 
> to a policy management daemon that will enforce such restriction more
> strongly, with the policy ensuring that the daemon can't be bypassed to
> directly manipulate the store.
>
> > How can I create a type that is structurally equivalent? (read all rules
> > associated with that type from the binary policy, and generate
> > allow/transition/etc. rules based on them?)
>
> Usually we do this by defining interfaces/macros in the policy itself,
> and then instantiating multiple types from it.  Rather than trying to
> automatically infer it.
Right, but in that case you are writing the policy, you are designing the 
policy. Considering the scenario I gave earlier, if the user/admin had known 
that he needs separate rules for those 2 programs, he wouldn't have put them 
in the same domain. Maybe it is just too complicated to handle this 
automatically, and fireflier should do just this:
  - let the user know what is the  domain of the program(s) accessing that 
socket
 - let the user decide if he wants _all_ the programs in that domain to give 
access, and if not (here comes the change):
      - let fireflier create a new type, that the user will(could) customize 
later
      - use a predefined domain (already in policy)
     - let the user modify the policy that only those programs remain in the 
same domain, that need same access rights

When fireflier creates a type, it would be based on unconfined_t by default.

After all, if the user has Selinux enabled on his system: 
 - he either knows how to write selinux policies, so he can customize the .te 
generated by fireflier
, or he uses a distro where the policy has already been written (properly), in 
which case he should choose from a list of predefined domains only




Edwin

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Török Edwin]

On Wednesday 26 April 2006 22:26, Stephen Smalley wrote:
> sediff of these two policies shows a _lot_ of differences, including 107
> added types in the "bad" policy.  Are you sure they are identical except
> for linking unconfined?  What is in that module (source)?
>
> I do see an allow unconfined_t security_t:security load_policy under a
> different boolean in the "bad" policy; looks like a boolean mapping
> problem at link time.  We did see those when the optionals-in-base
> support was first merged, so the Debian checkpolicy might have an issue
> there, but that should have been resolved in 1.30.3 or newer, built
> against libsepol 1.12.3 or newer.
>
I rebuilt the policy under FC5, with checkpolicy 1.30.3, and 
libsepol-1.12.4-1.fc5, checkpolicy-1.30.3-1.fc5, here it is
http://edwintorok.googlepages.com/policy.20.
Using sediff shows almost no difference to the bad policy (some te rules I 
removed, since they violated assertions), and the same 100+ differences to 
the good policy.
Looking at this line:
F               + allow unconfined_t security_t : security { compute_member 
compute_user compute_create setenforce check_context setcheckreqprot 
compute_relabel setbool load_policy setsecparam compute_av }; [ allow_execmem 
allow_execstack &&  ]

I tried setting allow_execmem and allow_execstack to true, and then I couldn't 
load policy anymore. Clearly, at linktime secure_mode_policyload was mapped 
to allow_execmem && allow_execstack. 
And AFAICT this bug it is still present in the latest checkpolicy+libsepol.

Is there a bugtracker for selinux?

(you said that  a bug like this has been fixed, do you recall where that patch 
is?, it might be a good starting point on fixing this issue)

Edwin

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeling only policy and problems with booleans

[Karl MacMillan]

On Thu, 2006-04-27 at 22:17 +0300, Török Edwin wrote:
> On Wednesday 26 April 2006 22:26, Stephen Smalley wrote:
> > sediff of these two policies shows a _lot_ of differences, including 107
> > added types in the "bad" policy.  Are you sure they are identical except
> > for linking unconfined?  What is in that module (source)?
> >
> > I do see an allow unconfined_t security_t:security load_policy under a
> > different boolean in the "bad" policy; looks like a boolean mapping
> > problem at link time.  We did see those when the optionals-in-base
> > support was first merged, so the Debian checkpolicy might have an issue
> > there, but that should have been resolved in 1.30.3 or newer, built
> > against libsepol 1.12.3 or newer.
> >
> I rebuilt the policy under FC5, with checkpolicy 1.30.3, and 
> libsepol-1.12.4-1.fc5, checkpolicy-1.30.3-1.fc5, here it is
> http://edwintorok.googlepages.com/policy.20.
> Using sediff shows almost no difference to the bad policy (some te rules I 
> removed, since they violated assertions), and the same 100+ differences to 
> the good policy.
> Looking at this line:
> F               + allow unconfined_t security_t : security { compute_member 
> compute_user compute_create setenforce check_context setcheckreqprot 
> compute_relabel setbool load_policy setsecparam compute_av }; [ allow_execmem 
> allow_execstack &&  ]
> 
> I tried setting allow_execmem and allow_execstack to true, and then I couldn't 
> load policy anymore. Clearly, at linktime secure_mode_policyload was mapped 
> to allow_execmem && allow_execstack. 
> And AFAICT this bug it is still present in the latest checkpolicy+libsepol.
> 
> Is there a bugtracker for selinux?
> 
> (you said that  a bug like this has been fixed, do you recall where that patch 
> is?, it might be a good starting point on fixing this issue)
> 
> Edwin
> 

We have a patch that fixes this, but unfortunately it is part of a
larger patch that fixes several bugs and introduces a minor policy
module file format change. I'm trying to track down the exact part of
the larger patch that fixes this bug now and will hopefully have a
smaller patch soon.

Karl

-- 
Karl MacMillan
Tresys Technology
www.tresys.com

> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[PATCH ] consistent labeling of block|character devices

[Török Edwin]

On Wednesday 26 April 2006 22:26, Stephen Smalley wrote:
>  However, ensuring a consistent label on devices
> irrespective of filesystem node used to access them would be nice; there
> has been some consideration of labeling the internal objects rather than
> just the filesystem nodes and applying access control at that layer to
> ensure consistent control. 
IMHO there are two approaches here: 
1) introduce a sid member in struct block_device and struct cdev
and then each time someone reads the sid of an inode of class 
SECCLASS_BLKFILE|SECCLASS_CHR_FILE, returns the sid of the associated device.
If relabeling is to be allowed, then relabeling the inode would mean 
relabeling the associated device.
But this would introduce additional overhead (the extra if to determine if we 
are dealing with device files) every time we read the sid of an inode. This 
seems not acceptable to me.

2) put a constant(invariant) label on devices, defined by policy
Policy would define what label a device with giver major/minor number.
We would then use this as the security context of the inode, no matter what 
its xattr would say.
So no matter how many device files we have pointing to the same device (same 
major/minor no.) all will have the same sid.

I tried putting an additional condition in inode_doinit_with_dentry, to 
compute the sid of block and character devices in a different way than for 
normal files. This would take care of initial labeling.
What should happen on relabeling, should the policy deny it (and we rely on 
that), or should some explicit code be added to return denied (somewhere in 
security_compute_av?) when tclass==SECCLASS_BLK_FILE||
tclass==SECCLASS_CHR_FILE, and requested==RELABEL_TO.

How time critical is inode_doinit_with_dentry, does adding an addittional if 
matter?

I am not sure how to implement map_device_to_sid, should I use 
selinux_genfs_context?

With the current policy language, what would be the easiest way of defining 
block device,character device initial sids?

And what would happen with modules that create block devices with dinamic 
major/minor numbers? How should those be labeled?

Any ideas,suggestions?

----
diff -uprN -X vanilla/linux-2.6.16/Documentation/dontdiff 
vanilla/linux-2.6.16/security/selinux/hooks.c 
linux-2.6.16/security/selinux/hooks.c
--- vanilla/linux-2.6.16/security/selinux/hooks.c	2006-03-20 
18:29:57.000000000 +0200
+++ linux-2.6.16/security/selinux/hooks.c	2006-05-01 18:27:05.000000000 +0300
@@ -731,7 +731,7 @@ static int inode_doinit_with_dentry(stru
 	hold_sem = 1;
 	if (isec->initialized)
 		goto out;
-
+   
 	sbsec = inode->i_sb->s_security;
 	if (!sbsec->initialized) {
 		/* Defer initialization until selinux_complete_init,
@@ -744,6 +744,18 @@ static int inode_doinit_with_dentry(stru
 		goto out;
 	}
 
+        int sclass = inode_mode_to_security_class(inode->i_mode);  
+        if(sclass == SECCLASS_BLK_FILE || sclass == SECCLASS_CHR_FILE)
+        {	
+	   char dev[16];
+	   isec->sclass = sclass;
+	   map_device_to_sid(inode->i_rdev,sclass,&sid);
+	   isec->sid=sid;
+	   isec->initialized=1;
+	   goto out;
+        }
+   
+
 	switch (sbsec->behavior) {
 	case SECURITY_FS_USE_XATTR:
 		if (!inode->i_op->getxattr) {
@@ -833,7 +845,7 @@ static int inode_doinit_with_dentry(stru
 		isec->sid = sbsec->sid;
 
 		/* Try to obtain a transition SID. */
-		isec->sclass = inode_mode_to_security_class(inode->i_mode);
+		isec->sclass = sclass;
 		rc = security_transition_sid(isec->task_sid,
 					     sbsec->sid,
 					     isec->sclass,
@@ -849,7 +861,7 @@ static int inode_doinit_with_dentry(stru
 		if (sbsec->proc) {
 			struct proc_inode *proci = PROC_I(inode);
 			if (proci->pde) {
-				isec->sclass = inode_mode_to_security_class(inode->i_mode);
+				isec->sclass = sclass;
 				rc = selinux_proc_get_sid(proci->pde,
 							  isec->sclass,
 							  &sid);

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH ] consistent labeling of block|character devices

[Stephen Smalley]

On Mon, 2006-05-01 at 19:06 +0300, Török Edwin wrote:
> On Wednesday 26 April 2006 22:26, Stephen Smalley wrote:
> >  However, ensuring a consistent label on devices
> > irrespective of filesystem node used to access them would be nice; there
> > has been some consideration of labeling the internal objects rather than
> > just the filesystem nodes and applying access control at that layer to
> > ensure consistent control. 
> IMHO there are two approaches here: 
> 1) introduce a sid member in struct block_device and struct cdev
> and then each time someone reads the sid of an inode of class 
> SECCLASS_BLKFILE|SECCLASS_CHR_FILE, returns the sid of the associated device.
> If relabeling is to be allowed, then relabeling the inode would mean 
> relabeling the associated device.
> But this would introduce additional overhead (the extra if to determine if we 
> are dealing with device files) every time we read the sid of an inode. This 
> seems not acceptable to me.

This assumes that the label of the filesystem node used to access the
device has to be the same as the label of the device itself.  Instead
consider labeling both objects and apply the appropriate access controls
at each layer.  Determining precisely the right objects to label and
control likely requires some investigation and discussion with the
maintainers of the driver core, e.g. Greg KH.

> 2) put a constant(invariant) label on devices, defined by policy
> Policy would define what label a device with giver major/minor number.
> We would then use this as the security context of the inode, no matter what 
> its xattr would say.
> So no matter how many device files we have pointing to the same device (same 
> major/minor no.) all will have the same sid.

This also makes the same assumption, and the device number is not really
a good way of identifying the devices and mapping them to labels,
particularly moving forward toward dynamic device numbers.

> I tried putting an additional condition in inode_doinit_with_dentry, to 
> compute the sid of block and character devices in a different way than for 
> normal files. This would take care of initial labeling.

I don't think this is the right approach.

> Any ideas,suggestions?

I think more investigation and discussion is required before we start
tossing code around, and requires the involvement of the relevant kernel
maintainers.  If you want to start such a dialogue just by asking the
relevant questions, feel free (but cc me and James Morris).  Greg is
likely a good starting point.  The hard part is asking the right
questions ;)

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[1/4] Labeling only policy for fireflier

[Török Edwin]

Hi,
[I have split this mail in several parts for easier reading.]

I have create a stripped down policy for use with fireflier. 
(for those who didn't read the entire thread: the purpose of this policy is to 
provide labels for sockets, to be used with skfilter/secmark)

This policy doesn't intend to protect from the actions of root (since as 
Stephen Smalley suggested that would eventually lead me closer to the strict 
policy).

So I made many types aliases, but I left the flask classess, initial sids, 
genfs intact.

If a user is not root is he able to override the security context of a 
process/file/socket? (relabel, or otherwise change context)

Furthermore, if a user is not root, load_policy/restorecon/setfiles won't 
function, am I right? Even if the user recompiles them (to remove any uid==0 
checks)?

I've also seen a capability named dac_override, it is needed when root needs 
to override dac (creating a file in the user's home directory, for example), 
but a user can't gain that capability, right? (IOW if DAC denies something, 
selinux won't allow it either)

So if I intend to provide no protection from root, I could use an even simpler 
base policy?

fireflier_base.conf:
-----------
class security
class process
class system
class capability
class filesystem
class file
class dir
class fd
class lnk_file
class chr_file
class blk_file
class sock_file
class fifo_file
class socket
class tcp_socket
class udp_socket
class rawip_socket
class node
class netif
class netlink_socket
class packet_socket
class key_socket
class unix_stream_socket
class unix_dgram_socket
class sem
class msg
class msgq
class shm
class ipc
class passwd			# userspace
class drawable			# userspace
class window			# userspace
class gc			# userspace
class font			# userspace
class colormap			# userspace
class property			# userspace
class cursor			# userspace
class xclient			# userspace
class xinput			# userspace
class xserver			# userspace
class xextension		# userspace
class pax
class netlink_route_socket
class netlink_firewall_socket
class netlink_tcpdiag_socket
class netlink_nflog_socket
class netlink_xfrm_socket
class netlink_selinux_socket
class netlink_audit_socket
class netlink_ip6fw_socket
class netlink_dnrt_socket
class dbus			# userspace
class nscd			# userspace
class association
class netlink_kobject_uevent_socket
sid kernel
sid security
sid unlabeled
sid fs
sid file
sid file_labels
sid init
sid any_socket
sid port
sid netif
sid netmsg
sid node
sid igmp_packet
sid icmp_socket
sid tcp_socket
sid sysctl_modprobe
sid sysctl
sid sysctl_fs
sid sysctl_kernel
sid sysctl_net
sid sysctl_net_unix
sid sysctl_vm
sid sysctl_dev
sid kmod
sid policy
sid scmp_packet
sid devnull
common file
{
	ioctl
	read
	write
	create
	getattr
	setattr
	lock
	relabelfrom
	relabelto
	append
	unlink
	link
	rename
	execute
	swapon
	quotaon
	mounton
}
common socket
{
	ioctl
	read
	write
	create
	getattr
	setattr
	lock
	relabelfrom
	relabelto
	append
	bind
	connect
	listen
	accept
	getopt
	setopt
	shutdown
	recvfrom
	sendto
	recv_msg
	send_msg
	name_bind
}	
common ipc
{
	create
	destroy
	getattr
	setattr
	read
	write
	associate
	unix_read
	unix_write
}
class filesystem
{
	mount
	remount
	unmount
	getattr
	relabelfrom
	relabelto
	transition
	associate
	quotamod
	quotaget
}
class dir
inherits file
{
	add_name
	remove_name
	reparent
	search
	rmdir
}
class file
inherits file
{
	execute_no_trans
	entrypoint
	execmod
}
class lnk_file
inherits file
class chr_file
inherits file
{
	execute_no_trans
	entrypoint
	execmod
}
class blk_file
inherits file
class sock_file
inherits file
class fifo_file
inherits file
class fd
{
	use
}
class socket
inherits socket
class tcp_socket
inherits socket
{
	connectto
	newconn
	acceptfrom
	node_bind
	name_connect
}
class udp_socket
inherits socket
{
	node_bind
}
class rawip_socket
inherits socket
{
	node_bind
}
class node 
{
	tcp_recv
	tcp_send
	udp_recv
	udp_send
	rawip_recv
	rawip_send
	enforce_dest
}
class netif
{
	tcp_recv
	tcp_send
	udp_recv
	udp_send
	rawip_recv
	rawip_send
}
class netlink_socket
inherits socket
class packet_socket
inherits socket
class key_socket
inherits socket
class unix_stream_socket
inherits socket
{
	connectto
	newconn
	acceptfrom
}
class unix_dgram_socket
inherits socket
class process
{
	fork
	transition
	sigchld # commonly granted from child to parent
	sigkill # cannot be caught or ignored
	sigstop # cannot be caught or ignored
	signull # for kill(pid, 0)
	signal  # all other signals
	ptrace
	getsched
	setsched
	getsession
	getpgid
	setpgid
	getcap
	setcap
	share
	getattr
	setexec
	setfscreate
	noatsecure
	siginh
	setrlimit
	rlimitinh
	dyntransition
	setcurrent
	execmem
	execstack
	execheap
}
class ipc
inherits ipc
class sem
inherits ipc
class msgq
inherits ipc
{
	enqueue
}
class msg
{
	send
	receive
}
class shm
inherits ipc
{
	lock
}
class security
{
	compute_av
	compute_create
	compute_member
	check_context
	load_policy
	compute_relabel
	compute_user
	setenforce     # was avc_toggle in system class
	setbool
	setsecparam
	setcheckreqprot
}
class system
{
	ipc_info
	syslog_read  
	syslog_mod
	syslog_console
}
class capability
{
	# The capabilities are defined in include/linux/capability.h
	# Care should be taken to ensure that these are consistent with
	# those definitions. (Order matters)
	chown           
	dac_override    
	dac_read_search 
	fowner          
	fsetid          
	kill            
	setgid           
	setuid           
	setpcap          
	linux_immutable  
	net_bind_service 
	net_broadcast    
	net_admin        
	net_raw          
	ipc_lock         
	ipc_owner        
	sys_module       
	sys_rawio        
	sys_chroot       
	sys_ptrace       
	sys_pacct        
	sys_admin        
	sys_boot         
	sys_nice         
	sys_resource     
	sys_time         
	sys_tty_config  
	mknod
	lease
	audit_write
	audit_control
}
class passwd
{
	passwd	# change another user passwd
	chfn	# change another user finger info
	chsh	# change another user shell
	rootok  # pam_rootok check (skip auth)
	crontab # crontab on another user
}
class drawable
{
	create
	destroy
	draw
	copy
	getattr
}
class gc
{
	create
	free
	getattr
	setattr
}
class window 
{
	addchild
	create
	destroy
	map
	unmap
	chstack
	chproplist
	chprop	
	listprop
	getattr
	setattr
	setfocus
	move
	chselection
	chparent
	ctrllife
	enumerate
	transparent
	mousemotion
	clientcomevent
	inputevent
	drawevent
	windowchangeevent
	windowchangerequest
	serverchangeevent
	extensionevent
}
class font
{
	load
	free
	getattr
	use
}
class colormap
{
	create
	free
	install
	uninstall
	list
	read
	store
	getattr
	setattr
}
class property
{
	create
	free
	read
	write
}
class cursor
{
	create
	createglyph
	free
	assign
	setattr
}
class xclient
{
	kill
}
class xinput
{
	lookup
	getattr
	setattr
	setfocus
	warppointer
	activegrab
	passivegrab
	ungrab
	bell
	mousemotion
	relabelinput
}
class xserver
{
	screensaver
	gethostlist
	sethostlist
	getfontpath
	setfontpath
	getattr
	grab
	ungrab
}
class xextension
{
	query
	use
}
class pax
{
	pageexec	# Paging based non-executable pages
	emutramp	# Emulate trampolines
	mprotect	# Restrict mprotect()
	randmmap	# Randomize mmap() base
	randexec	# Randomize ET_EXEC base
	segmexec	# Segmentation based non-executable pages
}
class netlink_route_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}
class netlink_firewall_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}
class netlink_tcpdiag_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}
class netlink_nflog_socket
inherits socket
class netlink_xfrm_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}
class netlink_selinux_socket
inherits socket
class netlink_audit_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
	nlmsg_relay
	nlmsg_readpriv
}
class netlink_ip6fw_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}
class netlink_dnrt_socket
inherits socket
class dbus
{
	acquire_svc
	send_msg
}
class nscd
{
	getpwd
	getgrp
	gethost
	getstat
	admin
	shmempwd
	shmemgrp
	shmemhost
}
class association
{
	sendto
	recvfrom
	setcontext
}
class netlink_kobject_uevent_socket
inherits socket
 # 8118 is for privoxy
attribute device_node;
attribute memory_raw_read;
attribute memory_raw_write;
attribute domain;
attribute unconfined_domain_type;
attribute set_curr_context;
attribute entry_type;
attribute privfd;
attribute can_change_process_identity;
attribute can_change_process_role;
attribute can_change_object_identity;
attribute can_system_change;
attribute process_user_target;
attribute cron_source_domain;
attribute cron_job_domain;
attribute process_uncond_exempt;	# add userhelperdomain to this one
attribute file_type;
attribute lockfile;
attribute mountpoint;
attribute pidfile;
attribute polydir;
attribute usercanread;
attribute polyparent;
attribute polymember;
attribute security_file_type;
attribute tmpfile;
attribute tmpfsfile;
attribute filesystem_type;
attribute noxattrfs;
attribute can_load_kernmodule;
attribute can_receive_kernel_messages;
attribute kern_unconfined;
attribute proc_type;
attribute sysctl_type;
attribute mcskillall;
attribute mlsfileread;
attribute mlsfilereadtoclr;
attribute mlsfilewrite;
attribute mlsfilewritetoclr;
attribute mlsfileupgrade;
attribute mlsfiledowngrade;
attribute mlsnetread;
attribute mlsnetreadtoclr;
attribute mlsnetwrite;
attribute mlsnetwritetoclr;
attribute mlsnetupgrade;
attribute mlsnetdowngrade;
attribute mlsnetrecvall;
attribute mlsipcread;
attribute mlsipcreadtoclr;
attribute mlsipcwrite;
attribute mlsipcwritetoclr;
attribute mlsprocread;
attribute mlsprocreadtoclr;
attribute mlsprocwrite;
attribute mlsprocwritetoclr;
attribute mlsprocsetsl;
attribute mlsxwinread;
attribute mlsxwinreadtoclr;
attribute mlsxwinwrite;
attribute mlsxwinwritetoclr;
attribute mlsxwinreadproperty;
attribute mlsxwinwriteproperty;
attribute mlsxwinreadcolormap;
attribute mlsxwinwritecolormap;
attribute mlsxwinwritexinput;
attribute mlstrustedobject;
attribute privrangetrans;
attribute mlsrangetrans;
attribute can_load_policy;
attribute can_setenforce;
attribute can_setsecparam;
attribute ttynode;
attribute ptynode;
attribute server_ptynode;
attribute serial_device;
attribute netif_type;
attribute node_type;
attribute port_type;
attribute reserved_port_type;

type selinux_config_t;
type init_t,domain;
type unconfined_t,domain;
type file_t alias {bin_t sbin_t}, file_type;
type default_t, file_type,mountpoint,filesystem_type;
type device_t alias {mtrr_device_t null_device_t bdev_t console_device_t 
zero_device_t devtty_t}, device_node;
type fs_t alias {sysfs_t usbfs_t usbdevfs_t debugfs_t root_t binfmt_misc_fs_t 
capifs_t configfs_t eventpollfs_t futexfs_t hugetlbfs_t inotifyfs_t nfsd_fs_t 
ramfs_t romfs_t rpc_pipefs_t autofs_t cifs_t dosfs_t iso9660_t nfs_t tmpfs_t 
devpts_t}, file_type,filesystem_type;
type kernel_t, can_load_kernmodule, file_type;
type proc_t alias {proc_mdstat_t proc_net_t} , proc_type, file_type;
type proc_kmsg_t , proc_type,file_type;
type proc_kcore_t, proc_type,file_type;
type sysctl_t alias {sysctl_irq_t sysctl_rpc_t sysctl_fs_t sysctl_kernel_t 
sysctl_modprobe_t sysctl_hotplug_t sysctl_net_t sysctl_net_unix_t sysctl_vm_t 
sysctl_dev_t}, sysctl_type,file_type;
type unlabeled_t;
type security_t,file_type;
type port_t, port_type,file_type;
type node_t, node_type,file_type;
type netif_t, netif_type,file_type;

bool secure_mode false;
bool secure_mode_insmod false;
bool secure_mode_policyload false;

typeattribute kernel_t can_change_process_identity;

allow device_t tmpfs_t:filesystem associate;
allow device_t fs_t:filesystem associate;
allow device_t noxattrfs:filesystem associate;


allow kernel_t file_t:dir mounton;
allow kernel_t root_t:dir mounton;
allow kernel_t self:dir { read getattr lock search ioctl };
allow kernel_t self:lnk_file { read getattr lock ioctl };
allow kernel_t self:file { getattr read write append ioctl lock };
# allow kernel_t to create child processes in this domain
allow kernel_t self:process { fork sigchld };
allow kernel_t self:capability *;
allow kernel_t unlabeled_t:dir mounton;
allow kernel_t self:process ~{ ptrace setcurrent setexec setfscreate setrlimit 
execmem execstack execheap };
allow kernel_t self:shm { associate getattr setattr create destroy read write 
lock unix_read unix_write };
allow kernel_t self:sem { associate getattr setattr create destroy read write 
unix_read unix_write };
allow kernel_t self:msg { send receive };
allow kernel_t self:msgq { associate getattr setattr create destroy read write 
enqueue unix_read unix_write };
allow kernel_t self:unix_dgram_socket { create { ioctl read getattr write 
setattr append bind connect getopt setopt shutdown } };
allow kernel_t self:unix_stream_socket { { create { ioctl read getattr write 
setattr append bind connect getopt setopt shutdown } } listen accept };
allow kernel_t self:unix_dgram_socket sendto;
allow kernel_t self:unix_stream_socket connectto;
allow kernel_t self:fifo_file { getattr read write append ioctl lock };
allow kernel_t self:sock_file { read getattr lock ioctl };
allow kernel_t self:fd use;
allow kernel_t proc_t:dir { read getattr lock search ioctl };
allow kernel_t proc_t:{ lnk_file file } { read getattr lock ioctl };
allow kernel_t proc_net_t:dir { read getattr lock search ioctl };
allow kernel_t proc_net_t:file { read getattr lock ioctl };
allow kernel_t proc_mdstat_t:file { read getattr lock ioctl };
allow kernel_t proc_kcore_t:file getattr;
allow kernel_t proc_kmsg_t:file getattr;
allow kernel_t sysctl_t:dir { read getattr lock search ioctl };
allow kernel_t sysctl_kernel_t:dir { read getattr lock search ioctl };
allow kernel_t sysctl_kernel_t:file { read getattr lock ioctl };
allow kernel_t unlabeled_t:fifo_file { getattr read write append ioctl lock };
allow kernel_t unlabeled_t:association { sendto recvfrom };
allow kernel_t netif_type:netif rawip_send;
#allow kernel_t self:capability net_raw;
allow kernel_t netif_type:netif rawip_recv;
allow kernel_t node_type:node rawip_send;
allow kernel_t node_type:node rawip_recv;
allow kernel_t netif_t:netif rawip_send;
#allow kernel_t self:capability net_raw;
allow kernel_t netif_type:netif { tcp_send tcp_recv };
allow kernel_t node_type:node { tcp_send tcp_recv };
allow kernel_t node_t:node rawip_send;
allow kernel_t sysfs_t:dir { read getattr lock search ioctl };
allow kernel_t sysfs_t:{ file lnk_file } { read getattr lock ioctl };
allow kernel_t usbfs_t:dir search;
allow kernel_t filesystem_type:filesystem mount;
allow kernel_t security_t:dir { read search getattr };
allow kernel_t security_t:file { getattr read write };
allow kernel_t security_t:security load_policy;
auditallow kernel_t security_t:security load_policy;
allow kernel_t device_t:dir { read getattr lock search ioctl };
allow kernel_t device_t:lnk_file { getattr read };
allow kernel_t console_device_t:chr_file { getattr read write append ioctl 
lock };
allow kernel_t bin_t:dir { read getattr lock search ioctl };
allow kernel_t bin_t:lnk_file { read getattr lock ioctl };
allow kernel_t sbin_t:dir { read getattr lock search ioctl };
allow kernel_t bin_t:dir { read getattr lock search ioctl };
allow kernel_t bin_t:lnk_file { read getattr lock ioctl };
allow kernel_t bin_t:file { { read getattr lock execute ioctl } 
execute_no_trans };
allow kernel_t domain:process signal;
allow kernel_t proc_t:dir search;
allow kernel_t domain:dir search;
allow kernel_t root_t:dir { read getattr lock search ioctl };
allow kernel_t root_t:lnk_file { read getattr lock ioctl };
allow kernel_t self:capability *;
allow kernel_t self:fifo_file { create ioctl read getattr lock write setattr 
append link unlink rename };
allow kernel_t self:process transition;
allow kernel_t self:file { getattr read write append ioctl lock };
allow kernel_t self:nscd *;
allow kernel_t self:dbus *;
allow kernel_t self:passwd *;
allow kernel_t proc_type:{ dir file } *;
allow kernel_t sysctl_t:{ dir file } *;
allow kernel_t kernel_t:system *;
allow kernel_t unlabeled_t:{ dir file lnk_file sock_file fifo_file chr_file 
blk_file } *;
allow kernel_t unlabeled_t:filesystem *;
allow kernel_t unlabeled_t:association *;
allow kernel_t { proc_t proc_net_t }:dir search;
allow kernel_t sysctl_type:dir { read getattr lock search ioctl };
allow kernel_t sysctl_type:file { { getattr read write append ioctl lock } 
setattr };
allow kernel_t node_type:node *;
allow kernel_t netif_type:netif *;
allow kernel_t port_type:tcp_socket { send_msg recv_msg name_connect };
allow kernel_t port_type:udp_socket { send_msg recv_msg };
allow kernel_t port_type:{ tcp_socket udp_socket rawip_socket } name_bind;
allow kernel_t node_type:{ tcp_socket udp_socket rawip_socket } node_bind;
allow kernel_t unlabeled_t:association { sendto recvfrom };
allow kernel_t device_node:{ chr_file blk_file } *;
allow kernel_t mtrr_device_t:{ dir file } *;
allow kernel_t self:capability sys_rawio;
allow kernel_t domain:{ { tcp_socket udp_socket rawip_socket netlink_socket 
packet_socket unix_stream_socket unix_dgram_socket netlink_route_socket 
netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket 
netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket 
netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket } 
socket key_socket } *;
allow kernel_t domain:fd use;
allow kernel_t domain:fifo_file { getattr read write append ioctl lock };
allow kernel_t domain:process ~{ transition dyntransition execmem execstack 
execheap };
allow kernel_t domain:{ sem msgq shm } *;
allow kernel_t domain:msg { send receive };
allow kernel_t domain:dir { read getattr lock search ioctl };
allow kernel_t domain:file { read getattr lock ioctl };
allow kernel_t domain:lnk_file { read getattr lock ioctl };
allow kernel_t file_type:{ file chr_file } ~execmod;
allow kernel_t file_type:{ dir lnk_file sock_file fifo_file blk_file } *;
allow kernel_t file_type:filesystem *;
allow kernel_t file_type:{ unix_stream_socket unix_dgram_socket } name_bind;
allow kernel_t file_type:file execmod;
allow kernel_t filesystem_type:filesystem *;
allow kernel_t filesystem_type:{ dir file lnk_file sock_file fifo_file 
chr_file blk_file } *;
allow kernel_t security_t:dir { getattr search read };
allow kernel_t security_t:file { getattr read write };
allow kernel_t security_t:security *;
auditallow kernel_t security_t:security { load_policy setenforce setbool };
allow kernel_t self:process execheap;
allow kernel_t self:process execmem;
allow kernel_t self:process execstack;
auditallow kernel_t self:process execstack;
auditallow kernel_t self:process execheap;
auditallow kernel_t self:process execmem;

allow kernel_t unlabeled_t:dir mounton;
allow kernel_t unlabeled_t:fifo_file { getattr read write append ioctl lock };
allow kernel_t unlabeled_t:association { sendto recvfrom };
allow kernel_t unlabeled_t:{ dir file lnk_file sock_file fifo_file chr_file 
blk_file } *;
allow kernel_t unlabeled_t:filesystem *;
allow kernel_t unlabeled_t:association *;
allow kernel_t unlabeled_t:association { sendto recvfrom };

allow kernel_t default_t:dir { read getattr lock search ioctl };
allow kernel_t default_t:file { read getattr lock ioctl };
allow kernel_t default_t:lnk_file { read getattr lock ioctl };
allow kernel_t default_t:sock_file { read getattr lock ioctl };
allow kernel_t default_t:fifo_file { read getattr lock ioctl };

allow file_type self:filesystem associate;
allow file_t fs_t:filesystem associate;
allow file_t noxattrfs:filesystem associate;

allow filesystem_type fs_t:filesystem associate;
allow filesystem_type noxattrfs:filesystem associate;

allow proc_t self:filesystem associate;

allow sysctl_t fs_t:filesystem associate;


allow unlabeled_t self:filesystem associate;

allow kernel_t security_t:dir { read search getattr };
allow kernel_t security_t:file { getattr read write };
typeattribute kernel_t can_load_policy;
if(!secure_mode_policyload) {
	allow kernel_t security_t:security load_policy;
	auditallow kernel_t security_t:security load_policy;
}
allow kernel_t security_t:dir { getattr search read };
allow kernel_t security_t:file { getattr read write };
typeattribute kernel_t can_load_policy, can_setenforce, can_setsecparam;
if(!secure_mode_policyload) {
	# Access the security API.
	allow kernel_t security_t:security *;
	auditallow kernel_t security_t:security { load_policy setenforce setbool };
}
typeattribute security_t filesystem_type;
allow security_t self:filesystem associate;
neverallow ~can_load_policy security_t:security load_policy;
neverallow ~can_load_kernmodule self:capability sys_module;
neverallow ~can_setenforce security_t:security setenforce;
neverallow ~can_setsecparam security_t:security setsecparam;


role system_r;
role user_r;
role system_r types kernel_t;
user system_u roles { system_r };
user user_u roles { user_r system_r };
user root roles { user_r system_r };

constrain process transition
	( u1 == u2
	or t1 == can_change_process_identity
);
constrain process transition 
	( r1 == r2
	or t1 == can_change_process_role
);
constrain process dyntransition
	( u1 == u2 and r1 == r2 );
constrain { dir file lnk_file sock_file fifo_file chr_file blk_file } { create 
relabelto relabelfrom } 
	( u1 == u2 or t1 == can_change_object_identity );
constrain { tcp_socket udp_socket rawip_socket netlink_socket packet_socket 
unix_stream_socket unix_dgram_socket netlink_route_socket 
netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket 
netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket 
netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket } { 
create relabelto relabelfrom } 
	( u1 == u2 or t1 == can_change_object_identity );

sid devnull system_u:object_r:null_device_t
sid file system_u:object_r:file_t
sid fs system_u:object_r:fs_t
sid kernel system_u:system_r:kernel_t
sid sysctl system_u:object_r:sysctl_t
sid unlabeled system_u:object_r:unlabeled_t
sid any_socket		system_u:object_r:unlabeled_t
sid file_labels		system_u:object_r:unlabeled_t
sid icmp_socket		system_u:object_r:unlabeled_t
sid igmp_packet		system_u:object_r:unlabeled_t
sid init			system_u:object_r:unlabeled_t
sid kmod			system_u:object_r:unlabeled_t
sid netmsg		system_u:object_r:unlabeled_t
sid policy		system_u:object_r:unlabeled_t
sid scmp_packet		system_u:object_r:unlabeled_t
sid sysctl_modprobe 	system_u:object_r:unlabeled_t
sid sysctl_fs		system_u:object_r:unlabeled_t
sid sysctl_kernel	system_u:object_r:unlabeled_t
sid sysctl_net		system_u:object_r:unlabeled_t
sid sysctl_net_unix	system_u:object_r:unlabeled_t
sid sysctl_vm		system_u:object_r:unlabeled_t
sid sysctl_dev		system_u:object_r:unlabeled_t
sid tcp_socket		system_u:object_r:unlabeled_t
sid security system_u:object_r:security_t
sid port system_u:object_r:port_t
sid node system_u:object_r:node_t
sid netif system_u:object_r:netif_t

fs_use_xattr ext2 system_u:object_r:fs_t;
fs_use_xattr ext3 system_u:object_r:fs_t;
fs_use_xattr gfs system_u:object_r:fs_t;
fs_use_xattr jfs system_u:object_r:fs_t;
fs_use_xattr reiserfs system_u:object_r:fs_t;
fs_use_xattr xfs system_u:object_r:fs_t;
fs_use_task sockfs system_u:object_r:fs_t;
fs_use_trans mqueue system_u:object_r:tmpfs_t;
fs_use_trans shm system_u:object_r:tmpfs_t;
fs_use_trans tmpfs system_u:object_r:tmpfs_t;
fs_use_trans devpts system_u:object_r:devpts_t;

genfscon proc /mtrr system_u:object_r:mtrr_device_t
genfscon sysfs / system_u:object_r:sysfs_t
genfscon usbfs / system_u:object_r:usbfs_t
genfscon usbdevfs / system_u:object_r:usbfs_t
genfscon rootfs / system_u:object_r:root_t
genfscon bdev / system_u:object_r:bdev_t
genfscon binfmt_misc / system_u:object_r:binfmt_misc_fs_t
genfscon capifs / system_u:object_r:capifs_t
genfscon configfs / system_u:object_r:configfs_t
genfscon eventpollfs / system_u:object_r:eventpollfs_t
genfscon futexfs / system_u:object_r:futexfs_t
genfscon hugetlbfs / system_u:object_r:hugetlbfs_t
genfscon inotifyfs / system_u:object_r:inotifyfs_t
genfscon nfsd / system_u:object_r:nfsd_fs_t
genfscon ramfs / system_u:object_r:ramfs_t
genfscon romfs / system_u:object_r:romfs_t
genfscon cramfs / system_u:object_r:romfs_t
genfscon rpc_pipefs / system_u:object_r:rpc_pipefs_t
genfscon autofs / system_u:object_r:autofs_t
genfscon automount / system_u:object_r:autofs_t
genfscon cifs / system_u:object_r:cifs_t
genfscon smbfs / system_u:object_r:cifs_t
genfscon fat / system_u:object_r:dosfs_t
genfscon msdos / system_u:object_r:dosfs_t
genfscon ntfs / system_u:object_r:dosfs_t
genfscon vfat / system_u:object_r:dosfs_t
genfscon iso9660 / system_u:object_r:iso9660_t
genfscon udf / system_u:object_r:iso9660_t
genfscon nfs / system_u:object_r:nfs_t
genfscon nfs4 / system_u:object_r:nfs_t
genfscon afs / system_u:object_r:nfs_t
genfscon debugfs / system_u:object_r:debugfs_t
genfscon proc / system_u:object_r:proc_t
genfscon proc /sysvipc system_u:object_r:proc_t
genfscon proc /kmsg system_u:object_r:proc_kmsg_t
genfscon proc /kcore system_u:object_r:proc_kcore_t
genfscon proc /mdstat system_u:object_r:proc_mdstat_t
genfscon proc /net system_u:object_r:proc_net_t
genfscon proc /sys system_u:object_r:sysctl_t
genfscon proc /irq system_u:object_r:sysctl_irq_t
genfscon proc /net/rpc system_u:object_r:sysctl_rpc_t
genfscon proc /sys/fs system_u:object_r:sysctl_fs_t
genfscon proc /sys/kernel system_u:object_r:sysctl_kernel_t
genfscon proc /sys/kernel/modprobe system_u:object_r:sysctl_modprobe_t
genfscon proc /sys/kernel/hotplug system_u:object_r:sysctl_hotplug_t
genfscon proc /sys/net system_u:object_r:sysctl_net_t
genfscon proc /sys/net/unix system_u:object_r:sysctl_net_unix_t
genfscon proc /sys/vm system_u:object_r:sysctl_vm_t
genfscon proc /sys/dev system_u:object_r:sysctl_dev_t
genfscon selinuxfs / system_u:object_r:security_t

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [2/4] Labeling only policy for fireflier (fireflier.pp)

[Török Edwin]

[this policy (together with the base in mail [1/4]) is intended for systems 
where there is no selinux by default. for selinux enabled systems i'll create 
modules to be used with reference policy, i'll send that in a separate mail 
when it will be ready]

Still I want to provide "some" protection against changing labels (it would be 
just too easy to escape protection, but only for root, right?)

So I implemented something similar to what selinuxutil.te does to protect the 
module store, and also restricted policy loading to only a few domains.
Also restricted policy loading/setbool/setenforce with booleans. Also 
restricted module loading, and rawio.

I didn't use the unconfined interfaces from the reference policy, since they 
allowed too much rights to programs (IMHO). So I modified them to fit my 
needs, and put them in unconfined_norelabel.if.

So nobody besides a domain with policymanager attribute can load policy, and 
nobody besides them are allowed to change the module store. 
Any bypasses?
Of course if somebody replaces load_policy he can load any policy (but that 
isn't possible with this policy, right?). If load_policy & friends aren't 
statically linked, than someone can bypass it by changing libc, and 
protecting against that brings me very close to strict policy. So let's 
assume that load_policy would be statically linked, and it would get a 
sanitized environment.

The module store is managed via semodule, so it has to have write access. The 
problem is whom I allow to execute semodule, because anybody doing that will 
override my policy. So I restricted transition to semanage_t only for 
policymanager domains.

Last I have a program named policymanager, that will generate the policy 
(doesn't exist yet). Obviously this will be the weakest link in the chain.
So in the end, I am not sure it is worth all this policy store protection, 
maybe I could do with a simpler policy.

Maybe just using auditallow&allow for loading policy protected with a boolean 
would be enough? (audit: so that the sysadmin thas the chance to know 
somebody changed the policy, if he uses remote logging, otherwise all is lost 
if somebody changes policy.) But then somebody could just replace the binary 
policy, and have it loaded automatically on next reboot?

(why i don't want too much protection against root: 
 - if somebody didn't have selinux, with fireflier 1.1.x somebody could just 
have deleted the iptables rules to bypass fireflier's protection. You can't 
get real protection against this, unless you use a strict policy,right?
Also I don't intend to make fireflier an selinux rule management tool,besides 
there are some nice tools from tresys that do that ;)
)




fireflier.te:
-----
policy_module(fireflier,0.1.0) 
########################################
#
# Declarations
#
gen_require(`
	      type file_t;
	      type sbin_t;
	      bool secure_mode_policyload;
	      bool secure_mode;
	      type selinux_config_t;
')
bool dac_override_audit true;

type fireflier_unconfined_t;

attribute can_unconfined_sockets;
attribute fireflier_unconfined_domain;
attribute has_restricted_sockets;

fireflier_unconfined(fireflier_unconfined_t,file_t,can_unconfined_sockets)
domain_auto_trans(fireflier_unconfined_domain,file_t,fireflier_unconfined_t)
kernel_domtrans_to(fireflier_unconfined_t,sbin_t)
neverallow fireflier_unconfined_t file_type:file {relabelfrom relabelto};

attribute policymanager;

gen_policymanager_type(load_policy)
gen_policymanager_type(boolset)
gen_policymanager_type(semanage)
gen_policymanager_type(restorecon)
gen_policymanager_type(policy_manager)
domain_auto_trans(fireflier_unconfined_domain,policy_manager_exec_t,policy_manager_t)

attribute policy_config;
type policy_config_t;
typeattribute policy_config_t policy_config;
typeattribute selinux_config_t policy_config;
#avoiding files_type(policy_config_t), because unconfined domains have access 
to all files
allow policy_config_t fs_t:filesystem associate;
allow selinux_config_t fs_t:filesystem associate;

type_transition domain policy_config_t:{dir file lnk_file} policy_config_t;
attribute can_relabelto_binary_policy;
neverallow ~can_relabelto_binary_policy policy_config_t:file relabelto;

type semanage_lock_t;
allow semanage_lock_t fs_t:filesystem associate;
allow load_policy_t semanage_lock_t:file rw_file_perms;
allow load_policy_t selinux_config_t:file rw_file_perms;
allow fireflier_unconfined_domain semanage_lock_t:file rw_file_perms;

typeattribute restorecon_t can_relabelto_binary_policy;
allow restorecon_t self:capability { dac_override dac_read_search fowner };
allow restorecon_t self:fifo_file rw_file_perms;
allow fireflier_unconfined_domain policy_config :dir r_dir_perms;
allow fireflier_unconfined_domain policy_config :file r_file_perms;
allow fireflier_unconfined_domain policy_config :lnk_file r_file_perms;
allow fireflier_unconfined_domain policy_config:dir search;

if(!secure_mode_policyload) {
	auditallow load_policy_t security_t:security {load_policy};
	allow load_policy_t security_t:security {load_policy};
	auditallow boolset_t security_t:security {setbool};
	allow boolset_t security_t:security {setbool};
	auditallow semanage_t policy_config_t:file { read write };
	allow semanage_t policy_config_t:file { read write lock create unlink 
rename};
	allow semanage_t selinux_config_t:file { read write lock create unlink 
rename};	
	allow semanage_t unlabeled_t:process sigchld;
	allow semanage_t policy_config_t:dir { read write getattr unlink create 
rename add_name remove_name rmdir};
	allow semanage_t selinux_config_t:dir { read write getattr unlink create 
rename add_name remove_name rmdir};
}
if(!secure_mode) {
	auditallow restorecon_t {selinux_config_t policy_config_t file_type}:{dir 
file} {relabelfrom relabelto};
	allow restorecon_t {selinux_config_t policy_config_t file_type}:{dir file} 
{relabelfrom relabelto};
}
#allow fireflier_unconfined_domain selinux_config_t:{dir file} *;


#from test_module

-----------
fireflier.if:
-------------
########################################
## <summary>
##      Make the specified domain unconfined.
##      Except that it does not allow it to change labels, and load policy
## </summary>
## <param name="domain">
##      <summary>
##      Domain to make unconfined.
##      </summary>
## </param>
## <param name="entrypoint">
##    <summary> 
##       File entry 
##    </summary>
## </param>
## <param name="attribute">
##    <summary> 
##       Attribute needed to get access to socket
##    </summary>
## </param>

#
interface(`fireflier_unconfined',`
        gen_require(`
            role system_r;
			attribute fireflier_unconfined_domain;
			type security_t;
			bool secure_mode;
			bool secure_mode_insmod;
			bool dac_override_audit;
        ')

        domain_type($1)
        domain_entry_file($1,$2)


        role system_r types $1;
		role user_r	  types $1;
		
		allow $1 self:capability ~{sys_module sys_rawio dac_override 
dac_read_search};
		if(!secure_mode && dac_override_audit) {
				 auditallow $1 self:capability {dac_override dac_read_search};
		}
		if (!secure_mode) {
		   allow $1 self:capability {dac_override dac_read_search};
		}
		
		allow $1 self:fifo_file create_file_perms;
		allow $1 self:process transition;
		allow $1 self:security ~{setenforce load_policy setbool setsecparam 
setcheckreqprot};
	 	allow $1 security_t:security ~{setenforce load_policy setbool setsecparam 
setcheckreqprot};
		
		kernel_unconfined_norelabel($1)
		kernel_load_module_safe($1)
		corenet_unconfined($1)
        dev_unconfined_norawio($1)
        domain_unconfined_norelabel($1)
        domain_dontaudit_read_all_domains_state($1)
        files_unconfined_norelabel($1)
        fs_unconfined_norelabel($1)

		typeattribute $1 $3;

		neverallow $1 domain:{file sock_file} {relabelfrom relabelto};
		neverallow ~$3 domain:{socket_class_set socket key_socket} *;
		
		allow $1 self:process execheap;
		allow $1 self:process execmem;
		allow $1 self:process execstack;
	        allow $1 self:{socket_class_set socket key_socket} *;
		
		allow $1 domain:process getattr;
		allow $1 device_t:{chr_file blk_file} getattr;
		allow $3 $1:{socket_class_set socket key_socket} *;
		typeattribute $1 fireflier_unconfined_domain;
')

########################################
## <summary>
##      Generates an unconfined domain.
##      Except that it does not allow it to change labels, and load policy
##      It will generate: $1_t,$1_exec_t,has_$1_socket_access
## </summary>
## <param name="domain">
##      <summary>
##		 Base name
##      </summary>
## </param>

#
interface(`fireflier_gen_unconfined_type',`
   gen_require(`
   		attribute has_restricted_sockets;
		type file_t;
		type fireflier_unconfined_t;
   ')
   type $1_t;
   type $1_exec_t;
   
   attribute has_$1_socket_access;
   files_type($1_exec_t)
   typeattribute $1_t has_restricted_sockets;
   fireflier_unconfined($1_t,$1_exec_t,has_$1_socket_access)
   domain_auto_trans(fireflier_unconfined_domain,$1_exec_t,$1_t)
#   domain_auto_trans($1_t,file_t,fireflier_unconfined_t)
')

########################################
## <summary>
## 	    Allows access for @domain to @restricted's sockets     
## </summary>
## <param name="domain">
##      <summary>
##		 The domain that needs access granted
##      </summary>
## </param>
## <param name="restricted">
##      <summary>
##		 The domain that has the restricted socket
##      </summary>
## </param>

#
interface(`allow_access_to_socket',`
    gen_require(`
    		 attribute has_$1_socket_access;
		 type $2_t;
    ')
    typeattribute $2_t has_$1_socket_access;
')

########################################
## <summary>
## 	    Unconfined type, that can modify the policy somehow
##	    Cannot be executed from other unconfined domains
## </summary>
## <param name="base">
##      <summary>
##		 The base name
##      </summary>

#
interface(`gen_policymanager_type',`
    gen_require(`
    		 attribute policymanager;
    ')
    type $1_t;
    type $1_exec_t;
   
    typeattribute $1_t policymanager;
    attribute has_$1_socket_access;
    fireflier_unconfined($1_t,$1_exec_t,has_$1_socket_access)
    neverallow ~policymanager $1_t:process transition;
    neverallow ~policymanager $1_exec_t:file {write unlink relabelfrom 
relabelto};
    domain_auto_trans(policymanager,$1_exec_t,$1_t)
')

---------------
fireflier.fc:
-------------
/etc/selinux/fireflier/modules/semanage.read.LOCK    --	
gen_context(system_u:object_r:semanage_lock_t,s0)
/etc/selinux/fireflier/modules/semanage.trans.LOCK   --	
gen_context(system_u:object_r:semanage_lock_t,s0)
/etc/selinux(/.*)?			gen_context(system_u:object_r:selinux_config_t,s0)
/etc/selinux/([^/]*/)?contexts(/.*)?                
gen_context(system_u:object_r:policy_config_t,s0)
/etc/selinux/([^/]*/)?policy(/.*)?	
gen_context(system_u:object_r:policy_config_t,s15:c0.c255)
/etc/selinux/([^/]*/)?seusers	--	
gen_context(system_u:object_r:selinux_config_t,s15:c0.c255)
/etc/selinux([^/]*/)?modules/(active|tmp|previous)(/.*)?     -- 
gen_context(system_u:object_r:policy_config_t,s0)
/etc/selinux/([^/]*/)?users(/.*)?	--	
gen_context(system_u:object_r:policy_config_t,s15:c0.c255)
/sbin/load_policy		--	gen_context(system_u:object_r:load_policy_exec_t,s0)
/usr/sbin/load_policy		--	gen_context(system_u:object_r:load_policy_exec_t,s0)
/sbin/restorecon		--	gen_context(system_u:object_r:restorecon_exec_t,s0)
/usr/sbin/semodule		--	gen_context(system_u:object_r:semanage_exec_t,s0)
/usr/sbin/setsebool	--	gen_context(system_u:object_r:boolset_exec_t,s0)
/usr/sbin/setenforce	--	gen_context(system_u:object_r:load_policy_exec_t,s0)

/usr/sbin/policymanager	-- 
gen_context(system_u:object_r:policy_manager_exec_t,s0)

unconfined_norelabel.if
----------
## <summary>fireflier policy generation</summary>
########################################
## <summary>
##      Unconfined access to devices, except rawio
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`dev_unconfined_norawio',`
        gen_require(`
                attribute device_node, memory_raw_write, memory_raw_read;
                type mtrr_device_t;
        ')
	allow $1 device_node:{ dir lnk_file sock_file fifo_file blk_file chr_file} *;
        allow $1 mtrr_device_t:{ dir file } *;
')
########################################
## <summary>
##      Unconfined access to domains, except relabeling
## </summary>
## <param name="domain">
##      <summary>
##      The type of the process performing this action.
##      </summary>
## </param>
#
interface(`domain_unconfined_norelabel',`
        gen_require(`
                attribute domain, set_curr_context;
		attribute has_restricted_sockets;
        ')
        # Use/sendto/connectto sockets created by any domain.
        allow $1 {domain - has_restricted_sockets}:{ socket_class_set socket 
key_socket } *;

        # Use descriptors and pipes created by any domain.
        allow $1 domain:fd use;
        allow $1 domain:fifo_file rw_file_perms;

        # Act upon any other process.
        allow $1 domain:process ~{ transition dyntransition execmem execstack 
execheap setcurrent};

        # Create/access any System V IPC objects.
        allow $1 domain:{ sem msgq shm } *;
        allow $1 domain:msg { send receive };

        # For /proc/pid
        allow $1 domain:dir r_dir_perms;
        allow $1 {domain}:file r_file_perms;
        allow $1 domain:lnk_file r_file_perms;
')

########################################
## <summary>
##      Unconfined access to kernel module resources, except relabeling
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`kernel_unconfined_norelabel',`
        gen_require(`
                type kernel_t, unlabeled_t, sysctl_t;
                attribute proc_type, sysctl_type;
                attribute kern_unconfined;
                attribute can_load_kernmodule, can_receive_kernel_messages;
        ')

        allow $1 proc_type:{ dir file } ~{relabelfrom relabelto};

        allow $1 sysctl_t:{ dir file } ~{relabelfrom relabelto};

        allow $1 kernel_t:system *;

        allow $1 unlabeled_t:dir_file_class_set ~{relabelfrom relabelto};
        allow $1 unlabeled_t:filesystem *;
        allow $1 unlabeled_t:association *;

        typeattribute $1 can_load_kernmodule, can_receive_kernel_messages;
        typeattribute $1 kern_unconfined;

        kernel_rw_all_sysctls($1)
')
########################################
## <summary>
##      Unconfined access to files, except relabeling
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`files_unconfined_norelabel',`
        gen_require(`
                attribute file_type;
        ')

        # Create/access any file in a labeled filesystem;
        allow $1 file_type:{ file chr_file} ~{ execmod relabelfrom 
relabelto };
        allow $1 file_type:{ dir lnk_file fifo_file blk_file } *;
#	allow $1 {file_type -has_restricted_sockets}:sock_file *;
	allow $1 file_type:sock_file *;

        # Mount/unmount any filesystem with the context= option.
        allow $1 file_type:filesystem *;

        # Bind to any network address.
        # cjp: need to check this, I dont think this has any effect.
        allow $1 file_type:{ unix_stream_socket unix_dgram_socket } name_bind;

        allow $1 file_type:file execmod;
')

########################################
## <summary>
##      Unconfined access to filesystems, except relabeling
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`fs_unconfined_norelabel',`
        gen_require(`
                attribute filesystem_type;
        ')

        allow $1 filesystem_type:filesystem ~{relabelfrom relabelto};

        # Create/access other files.  fs_type is to pick up various
        # pseudo filesystem types that are applied to both the filesystem
        # and its files.
        allow $1 filesystem_type:{ dir file lnk_file sock_file fifo_file } 
~{relabelfrom relabelto};
	allow $1 filesystem_type:{ blk_file chr_file } *;
')

########################################
## <summary>
##	Allows caller to load kernel modules, if !secure_mode_insmod
## </summary>
## <param name="domain">
##	<summary>
##	The process type to allow to load kernel modules.
##	</summary>
## </param>
#
interface(`kernel_load_module_safe',`
	gen_require(`
		attribute can_load_kernmodule;
	')
	if(!secure_mode_insmod) {
				allow $1 self:capability sys_module;
				}
				typeattribute $1 can_load_kernmodule;

')

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[3/4] Labeling only policy for fireflier (example module)

[Török Edwin]

This is an example module that fireflier would generate for a certain program.

myapp1_t's sockets can only be accesses by myapp2, but not by other unconfined 
processes, and not by myapp3.
myapp2, and myapp3's sockets can't be accesses except by themselves.
fireflier_unconfined_t's sockets can be accessed by anybody.


I included the policy files, and a test program below.
Let's suppose these programs aren't run as root. Can they bypass selinux 
security context labels?(can they change them?)



test_module.te:
--------------
policy_module(test_module,0.1)
fireflier_gen_unconfined_type(myapp1)
fireflier_gen_unconfined_type(myapp2)
fireflier_gen_unconfined_type(myapp3)

allow_access_to_socket(myapp1,myapp2)

------
test_module.fc
-----
/home/edwin/p2          --      
gen_context(system_u:object_r:myapp2_exec_t,s0)
/home/edwin/p3          --      gen_context(system_u:object_r:myapp3_exec_t,s0
/home/edwin/p1          --      
gen_context(system_u:object_r:myapp1_exec_t,s0)
/home/edwin/p4          --      
gen_context(system_u:object_r:myapp1_exec_t,s0)



--------------p1.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
void die(const char* msg)
{
   perror(msg);
   exit(1);
}

void showattr(int fd)
{
   const char security_name[] = "security.selinux";
   ssize_t len = fgetxattr(fd,security_name,NULL,0);
   if (len==-1)
     return;
   

   size_t i;

   char* list = malloc(len+1);
   if((len = fgetxattr(fd,security_name,list,len))==-1)
     die("error getting xattr");
   list[len]=0;
   for(i=0;i<len;i++)
     if(!list[i]) list[i]='\n';   
   printf("\nsecurity context of %d  is: %s",fd,list);
   free(list);

}
   

int main(int argc,char* argv[])
{
   if(argc<3) 
     {
	printf("usage: %s <childname> <port>\n",argv[0]);
	return 1;
     }
   
   int fd = socket(PF_INET,SOCK_STREAM,IPPROTO_TCP);
   if(fd<0)
     die("socket() failed");
   struct sockaddr_in servaddr;
   servaddr.sin_family = AF_INET;
   servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
   servaddr.sin_port = htons(atoi(argv[2]));
   if(bind(fd,(struct sockaddr*)&servaddr,sizeof(servaddr))<0)
     die("bind() failed");
   if(listen(fd,3)<0)
     die("listen() failed");
   int newfd2 =  accept(fd,NULL,NULL);
   if(newfd2<0)
     die("accept() failed");

   showattr(fd);
   showattr(newfd2);
   system(argv[1]);
   if(fork()==0) 
     {   
	execl(argv[1],argv[1],(char*)NULL);
     }
   
   close(newfd2);
   close(fd);
   return 0;
}

-------------p2.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <unistd.h>
#include <attr/xattr.h>
#include <string.h>
#include <netinet/in.h>

void die(const char* msg)
{
   perror(msg);
   exit(1);
}

char* linkname(int fd)
{
   char fmt[] = "/proc/self/fd/%d";
   const int namebufsiz = strlen(fmt)+16;
   char* namebuf = malloc(namebufsiz);
   char* buf = NULL;
   
   snprintf(namebuf,namebufsiz,fmt,fd);
   int res = 0,bufsiz=0;
   do{
      bufsiz += 16;
      buf  = realloc(buf,bufsiz);
      res = readlink(namebuf,buf,bufsiz);
      if (res == -1)
	die("readlink error");
   } while (res==bufsiz);
   free(namebuf);
   return buf;  
}


void showattr(int fd)
{
   const char security_name[] = "security.selinux";
   ssize_t len = fgetxattr(fd,security_name,NULL,0);
   if (len==-1)
     return;
   
   char* name = linkname(fd);
   size_t i;

   char* list = malloc(len+1);
   if((len = fgetxattr(fd,security_name,list,len))==-1)
     die("error getting xattr");
   list[len]=0;
   for(i=0;i<len;i++)
     if(!list[i]) list[i]='\n';   
   printf("\nsecurity context of %d (%s) is: %s",fd,name,list);
   free(name);
   free(list);

   struct stat sbuf;
   if(fstat(fd,&sbuf)==-1)
     perror("stat error");
   else 
     {
	if(!S_ISSOCK(sbuf.st_mode)) 
	  {
	     printf("not a socket");
	     if(fd<3)
	       return;
	  }	
     }
   
   //read from it
   char x[16];
   socklen_t socklen = 16;
   struct sockaddr* sa=malloc(socklen);
   struct msghdr msg;
   if(read(fd,x,sizeof(x))==-1)
     perror("read failed");
   else
     printf("%s\n",x);
   if(recv(fd,&x,1,MSG_DONTWAIT)==-1)
     perror("recv failed");
   if(recvfrom(fd,&x,1,MSG_DONTWAIT,sa,&socklen)==-1)
     perror("recvfrom failed");
   if(recvmsg(fd,&msg,MSG_DONTWAIT)==-1)
     perror("recvmsg failed");
   if(listen(fd,3)<0)
     perror("listen failed");
   if(accept(fd,NULL,NULL))
     perror("accept failed");
   struct sockaddr_in servaddr;
   servaddr.sin_family = AF_INET;
   servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
   servaddr.sin_port = htons(5611);
   if(connect(fd,(struct sockaddr*)&servaddr,sizeof(servaddr))<0)
     perror("connect failed");
   if(bind(fd,(struct sockaddr*)&servaddr,sizeof(servaddr))<0)
     perror("bind failed");
}


int main()
{
   int fds,fd;
   if((fds = getdtablesize()) == -1) fds=255;
   for(fd=0;fd<fds;fd++)
     showattr(fd);
   system("ps -Z");
}

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [2/4] Labeling only policy for fireflier (fireflier.pp)

[Christopher J. PeBenito]

On Mon, 2006-05-01 at 19:34 +0300, Török Edwin wrote:
> [this policy (together with the base in mail [1/4]) is intended for systems 
> where there is no selinux by default. for selinux enabled systems i'll create 
> modules to be used with reference policy, i'll send that in a separate mail 
> when it will be ready]
> 
> Still I want to provide "some" protection against changing labels (it would be 
> just too easy to escape protection, but only for root, right?)

Even if you can't relabel the file you could just delete it and recreate
it with the new label using setfscreatecon, since it has all the other
file perms.

> So I implemented something similar to what selinuxutil.te does to protect the 
> module store, and also restricted policy loading to only a few domains.
> Also restricted policy loading/setbool/setenforce with booleans. Also 
> restricted module loading, and rawio.
> 
> I didn't use the unconfined interfaces from the reference policy, since they 
> allowed too much rights to programs (IMHO). So I modified them to fit my 
> needs, and put them in unconfined_norelabel.if.
> 
> So nobody besides a domain with policymanager attribute can load policy, and 
> nobody besides them are allowed to change the module store. 
> Any bypasses?

It looks like you have raw disk access, so thats at least one.  It may
not allow you to load the policy, but it allows you to modify the policy
on disk, and next time its loaded (e.g., reboot), you get the modified
policy.

> Of course if somebody replaces load_policy he can load any policy (but that 
> isn't possible with this policy, right?).

You have to have the load_policy permission or transition to a domain
that has the permission.  If you have neither of these, then you should
be ok.  The catch is if you can alter the policy (see above), then you
could get someone else to load the policy (e.g., reboot).  If you can
alter the load_policy binary or its libraries then you could make it do
anything within limits of the domain it runs in.

>  If load_policy & friends aren't 
> statically linked, than someone can bypass it by changing libc, and 
> protecting against that brings me very close to strict policy. So let's 
> assume that load_policy would be statically linked, and it would get a 
> sanitized environment.

See above comment.

> The module store is managed via semodule, so it has to have write access. The 
> problem is whom I allow to execute semodule, because anybody doing that will 
> override my policy. So I restricted transition to semanage_t only for 
> policymanager domains.
> 
> Last I have a program named policymanager, that will generate the policy 
> (doesn't exist yet). Obviously this will be the weakest link in the chain.
> So in the end, I am not sure it is worth all this policy store protection, 
> maybe I could do with a simpler policy.
> 
> Maybe just using auditallow&allow for loading policy protected with a boolean 
> would be enough? (audit: so that the sysadmin thas the chance to know 
> somebody changed the policy, if he uses remote logging, otherwise all is lost 
> if somebody changes policy.) But then somebody could just replace the binary 
> policy, and have it loaded automatically on next reboot?

Right.

> (why i don't want too much protection against root: 
>  - if somebody didn't have selinux, with fireflier 1.1.x somebody could just 
> have deleted the iptables rules to bypass fireflier's protection. You can't 
> get real protection against this, unless you use a strict policy,right?

So off the top of my head, it sounds like the policy should at least
restrict net_admin capability, protect all the files that iptables_t
accesses and its libraries, protect the policy, protect policy loading,
protect load_policy and its libraries.  That affects a lot of files
since it includes some generic types like etc_t, lib_t, and shlib_t.

> Also I don't intend to make fireflier an selinux rule management tool,besides 
> there are some nice tools from tresys that do that ;)
> )

You should try out apol from setools to help analyze your policy.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[4/4] Labeling only policy for fireflier (install)

[Török Edwin]

This is an install script I would use to install this policy.
I put those mkdir/touch there, because otherwise semodule failed on a system 
with no policy installed.
Is anything I should watch out for when installing policy on a system that 
doesn't yet have selinux policy? (but it has the required libs, and binaries 
from policycoreutils).

This install script is to be used before selinux is enabled (i.e. selinux=0 on 
boot), and then doing a reboot with selinux=1 should "just work" (i.e. 
without any avc denied messages on boot).

I tested this on a virtual machine, and will test it on different 
distributions on real machines soon, but in the meantime has anybody 
encountered any problems when setting up selinux?
(I encountered a segfault with semodule, but it got fixed with an upgrade of 
libs+tools, not sure which package/version fixed it)

base contains fireflier_base.pp generated from fireflier_base.conf (see [1/4])
generator contains fireflier.pp generated from fireflier.te, fireflier.fc, 
fireflier.if, unconfined_norelabel.if (see [2/4])

------install.sh
#!/bin/sh
AWK=awk
SEMODULE=/usr/sbin/semodule

SELINUX_ROOT=/etc/selinux
SELINUX_CONFIG=$SELINUX_ROOT/config
SELINUX_CONFIG_OLD=$SELINUX_ROOT/config.old
SELINUX_SEMANAGE_CONF=$SELINUX_ROOT/semanage.conf

FIREFLIER_POLICY_NAME=fireflier
FIREFLIER_POLICY_ROOT=$SELINUX_ROOT/$FIREFLIER_POLICY_NAME
FIREFLIER_POLICY_BASE=base/fireflier_base.pp
FIREFLIER_POLICY_BASE_MOD=generator/fireflier.pp





if [ ! -e $SELINUX_SEMANAGE_CONF ]; then
     echo "You don't have an semanage.conf file, creating one";
     cat >$SELINUX_SEMANAGE_CONF <<EOF
# Specify how libsemanage will interact with a SELinux policy manager.
# The four options are:
#
#  "source"     - libsemanage manipulates a source SELinux policy
#  "direct"     - libsemanage will write directly to a module store.
#  /foo/bar     - Write by way of a policy management server, whose
#                 named socket is at /foo/bar.  The path must begin
#                 with a '/'.
#  foo.com:4242 - Establish a TCP connection to a remote policy
#                 management server at foo.com.  If there is a colon
#                 then the remainder is interpreted as a port number;
#                 otherwise default to port 4242.
module-store = direct

# When generating the final linked and expanded policy, by default
# semanage will set the policy version to POLICYDB_VERSION_MAX, as
# given in <sepol/policydb.h>.  Change this setting if a different
# version is necessary.
#policy-version = 19     
EOF
fi
 

mkdir -p $FIREFLIER_POLICY_ROOT
mkdir -p $FIREFLIER_POLICY_ROOT/policy
mkdir -p $FIREFLIER_POLICY_ROOT/modules
mkdir -p $FIREFLIER_POLICY_ROOT/modules/active
mkdir -p $FIREFLIER_POLICY_ROOT/contexts
mkdir -p $FIREFLIER_POLICY_ROOT/contexts/files
touch $FIREFLIER_POLICY_ROOT/modules/active/policy.kern
touch $FIREFLIER_POLICY_ROOT/modules/active/homedir_template
touch $FIREFLIER_POLICY_ROOT/modules/active/file_contexts
touch $FIREFLIER_POLICY_ROOT/modules/active/seusers.final


$SEMODULE -v -b $FIREFLIER_POLICY_BASE -s $FIREFLIER_POLICY_NAME
$SEMODULE -v -i $FIREFLIER_POLICY_BASE_MOD -s $FIREFLIER_POLICY_NAME

if [ -e $SELINUX_CONFIG_OLD ]; then
    echo "";
    echo "  $SELINUX_CONFIG_OLD already exists, please move it to a safe 
place, and then delete it";
    echo "  Aborting script!";
exit;
fi

if [ -e $SELINUX_CONFIG ]; then
   echo "Backing up SELinux configuration $SELINUX_CONFIG to 
$SELINUX_CONFIG_OLD"
   cp $SELINUX_CONFIG $SELINUX_CONFIG_OLD
   echo "Switching to $FIREFLIER_POLICY_NAME policy"
   CURRENT_TYPE=`$AWK -F= '/^SELINUXTYPE/{ print $2 }' $SELINUX_CONFIG`
   sed -s s/$CURRENT_TYPE/$FIREFLIER_POLICY_NAME/ $SELINUX_CONFIG_OLD > 
$SELINUX_CONFIG
   echo "Switching to enforcing mode"
   CURRENT_MODE=`$AWK -F= '/^SELINUX=/{ print $2 }' $SELINUX_CONFIG`
   sed -s s/$CURRENT_MODE/enforcing/ $SELINUX_CONFIG_OLD > $SELINUX_CONFIG
else
   echo "Generating initial policy config"
   mkdir -p $SELINUX_ROOT
   cat >$SELINUX_CONFIG <<EOF
# used by init
SELINUX=enforcing
# active policy
SELINUXTYPE=fireflier
EOF
fi

echo "Setting up initial labels on critical locations"
setfiles $FIREFLIER_POLICY_ROOT/contexts/files/file_contexts 
$FIREFLIER_POLICY_ROOT /sbin /usr/sbin /etc/selinux/config
chcon system_u:object_r:semanage_lock_t $FIREFLIER_POLICY_ROOT/modules/*.LOCK

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [1/4] Labeling only policy for fireflier

[Christopher J. PeBenito]

On Mon, 2006-05-01 at 19:17 +0300, Török Edwin wrote:
> Hi,
> [I have split this mail in several parts for easier reading.]
> 
> I have create a stripped down policy for use with fireflier. 
> (for those who didn't read the entire thread: the purpose of this policy is to 
> provide labels for sockets, to be used with skfilter/secmark)

It would be better if you could give the source files and/or a diff from
reference policy, rather than expanded base.conf, etc.  It'll be much
simpler to understand.

> This policy doesn't intend to protect from the actions of root (since as 
> Stephen Smalley suggested that would eventually lead me closer to the strict 
> policy).
> 
> So I made many types aliases, but I left the flask classess,

Just so you know, you definitely wouldn't want to change the classes;
they need to match up with the kernel.

>  initial sids, 
> genfs intact.

I think this can answer your remaining questions: SELinux checks are in
addition to the regular linux DAC; thus, users can, at most, do the same
things they can do on a regular linux system.  If something is denied by
linux DAC it won't even get to the SELinux checks.

> If a user is not root is he able to override the security context of a 
> process/file/socket? (relabel, or otherwise change context)
> 
> Furthermore, if a user is not root, load_policy/restorecon/setfiles won't 
> function, am I right? Even if the user recompiles them (to remove any uid==0 
> checks)?
> 
> I've also seen a capability named dac_override, it is needed when root needs 
> to override dac (creating a file in the user's home directory, for example), 
> but a user can't gain that capability, right? (IOW if DAC denies something, 
> selinux won't allow it either)
> 
> So if I intend to provide no protection from root, I could use an even simpler 
> base policy?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [1/4] Labeling only policy for fireflier

[Török Edwin]

On Monday 01 May 2006 21:55, Christopher J. PeBenito wrote:
> On Mon, 2006-05-01 at 19:17 +0300, Török Edwin wrote:
> > Hi,
> > [I have split this mail in several parts for easier reading.]
> >
> > I have create a stripped down policy for use with fireflier.
> > (for those who didn't read the entire thread: the purpose of this policy
> > is to provide labels for sockets, to be used with skfilter/secmark)
>
> It would be better if you could give the source files and/or a diff from
> reference policy, rather than expanded base.conf, etc.  It'll be much
> simpler to understand.
I have sent the diff inline in my previous mail, unfortunately it was too 
large (exceeded this mailing list's maximum).Sorry about this.

I uploaded the policy diffs here:
 http://edwintorok.googlepages.com/policy.diff
 http://edwintorok.googlepages.com/conf.diff

Policy.diff is the diff of my modifications to reference policy.
I used the reference policy, with these modules in base:
selinux,files,filesystem,kernel,domain,corenetwork. I then hand-edited the 
generated conf file, making certain types aliases, and removed the portcon 
statements.
Conf.diff is the diff of base.conf generated by a reference policy build, and 
my fireflier_base.conf.




Edwin


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[RFC][PATCH 3/7] sidtab - hashtable to store SIDs

[Török Edwin]

This is the sidtab.c from SELinux, adapted to use the context structure 
specific to fireflier.

This patch is not meant to modify sidtab.c from SELinux!
It is meant to copy sidtab.c from SELinux, make the required changes, and put 
it into the fireflier_lsm directory.

How can I prevent this code duplication? I'd prefer not to duplicate files 
like this.

---
 sidtab.c |   42 ++++++++++++++++++++----------------------
 sidtab.h |   34 ++++++++++++++++------------------
 2 files changed, 36 insertions(+), 40 deletions(-)

--- /home/edwin/kernel/linux-2.6.16/security/selinux/ss/sidtab.c	2006-02-10 
09:22:48.000000000 +0200
+++ fireflier_lsm/sidtab.c	2006-04-07 15:06:00.000000000 +0300
@@ -1,16 +1,19 @@
 /*
  * Implementation of the SID table type.
  *
- * Author : Stephen Smalley, <sds@epoch.ncsc.mil>
+ * Heavily based on selinux/ss/sidtab.c
+ * Original author : Stephen Smalley, <sds@epoch.ncsc.mil>
+ *
+ * Modified for fireflier by: Török Edwin <edwin@gurde.com>
  */
+
 #include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/errno.h>
 #include <linux/sched.h>
-#include "flask.h"
-#include "security.h"
 #include "sidtab.h"
+#include "constants.h"
 
 #define SIDTAB_HASH(sid) \
 (sid & SIDTAB_HASH_MASK)
@@ -29,13 +32,13 @@ int sidtab_init(struct sidtab *s)
 	for (i = 0; i < SIDTAB_SIZE; i++)
 		s->htable[i] = NULL;
 	s->nel = 0;
-	s->next_sid = 1;
+	s->next_sid = FIREFLIER_SECINITSID_KERNEL+1;
 	s->shutdown = 0;
 	INIT_SIDTAB_LOCK(s);
 	return 0;
 }
 
-int sidtab_insert(struct sidtab *s, u32 sid, struct context *context)
+int sidtab_insert(struct sidtab *s, u32 sid, const struct context *context)
 {
 	int hvalue, rc = 0;
 	struct sidtab_node *prev, *cur, *newnode;
@@ -64,12 +67,7 @@ int sidtab_insert(struct sidtab *s, u32 
 		goto out;
 	}
 	newnode->sid = sid;
-	if (context_cpy(&newnode->context, context)) {
-		kfree(newnode);
-		rc = -ENOMEM;
-		goto out;
-	}
-
+	context_cpy(&newnode->context,context);
 	if (prev) {
 		newnode->next = prev->next;
 		wmb();
@@ -83,10 +81,10 @@ int sidtab_insert(struct sidtab *s, u32 
 	s->nel++;
 	if (sid >= s->next_sid)
 		s->next_sid = sid + 1;
 	return rc;
 }
 
-struct context *sidtab_search(struct sidtab *s, u32 sid)
+const struct context *sidtab_search(struct sidtab *s, u32 sid)
 {
 	int hvalue;
 	struct sidtab_node *cur;
@@ -102,7 +100,7 @@ struct context *sidtab_search(struct sid
 
 	if (cur == NULL || sid != cur->sid) {
 		/* Remap invalid SIDs to the unlabeled SID. */
-		sid = SECINITSID_UNLABELED;
+		sid = FIREFLIER_SID_UNLABELED;
 		hvalue = SIDTAB_HASH(sid);
 		cur = s->htable[hvalue];
 		while (cur != NULL && sid > cur->sid)
@@ -111,6 +109,6 @@ struct context *sidtab_search(struct sid
 			return NULL;
 	}
 
-	return &cur->context;
+	return cur->context;
 }
 

 void sidtab_map_remove_on_error(struct sidtab *s,
 				int (*apply) (u32 sid,
-					      struct context *context,
+					      const struct context *context,
 					      void *args),
 				void *args)
 {
@@ -155,7 +129,7 @@ void sidtab_map_remove_on_error(struct s
 		last = NULL;
 		cur = s->htable[i];
 		while (cur != NULL) {
-			ret = apply(cur->sid, &cur->context, args);
+			ret = apply(cur->sid, cur->context, args);
 			if (ret) {
 				if (last) {
 					last->next = cur->next;
@@ -165,7 +139,7 @@ void sidtab_map_remove_on_error(struct s
 
 				temp = cur;
 				cur = cur->next;
-				context_destroy(&temp->context);
+				kfree(temp->context);
 				kfree(temp);
 				s->nel--;
 			} else {
@@ -179,7 +153,7 @@ void sidtab_map_remove_on_error(struct s
 }
 
 static inline u32 sidtab_search_context(struct sidtab *s,
-						  struct context *context)
+					const struct context *context)
 {
 	int i;
 	struct sidtab_node *cur;
@@ -187,7 +161,7 @@ static inline u32 sidtab_search_context(
 	for (i = 0; i < SIDTAB_SIZE; i++) {
 		cur = s->htable[i];
 		while (cur != NULL) {
-			if (context_cmp(&cur->context, context))
+			if (context_cmp(cur->context, context))
 				return cur->sid;
 			cur = cur->next;
 		}
@@ -196,14 +170,14 @@ static inline u32 sidtab_search_context(
 }
 
 int sidtab_context_to_sid(struct sidtab *s,
-			  struct context *context,
+			  const struct context *context,
 			  u32 *out_sid)
 {
 	u32 sid;
 	int ret = 0;
 	unsigned long flags;
 
-	*out_sid = SECSID_NULL;
+	*out_sid = FIREFLIER_SID_UNLABELED;
 
 	sid = sidtab_search_context(s, context);
 	if (!sid) {
@@ -221,7 +195,7 @@ int sidtab_context_to_sid(struct sidtab 
 		ret = sidtab_insert(s, sid, context);
 		if (ret)
 			s->next_sid--;
 		SIDTAB_UNLOCK(s, flags);
 	}
 
@@ -272,7 +246,7 @@ void sidtab_destroy(struct sidtab *s)
 		while (cur != NULL) {
 			temp = cur;
 			cur = cur->next;
-			context_destroy(&temp->context);
+			kfree(temp->context);
 			kfree(temp);
 		}
 		s->htable[i] = NULL;
@@ -283,18 +257,6 @@ void sidtab_destroy(struct sidtab *s)
 	s->next_sid = 1;
 }
 
--- /home/edwin/kernel/linux-2.6.16/security/selinux/ss/sidtab.h	2006-02-10 
09:22:48.000000000 +0200
+++ fireflier_lsm/sidtab.h	2006-03-29 23:23:57.000000000 +0300
@@ -1,20 +1,24 @@
 /*
  * A security identifier table (sidtab) is a hash table
- * of security context structures indexed by SID value.
+ * of (executable) file structures indexed by SID value.
  *
- * Author : Stephen Smalley, <sds@epoch.ncsc.mil>
+ * Heavily based on selinux/ss/sidtab.h
+ * Original author : Stephen Smalley, <sds@epoch.ncsc.mil>
+ *
+ * Modified for fireflier by: Török Edwin <edwin@gurde.com>
  */
-#ifndef _SS_SIDTAB_H_
-#define _SS_SIDTAB_H_
+#ifndef _FF_SIDTAB_H_
+#define _FF_SIDTAB_H_
 
 #include "context.h"
-
-struct sidtab_node {
-	u32 sid;		/* security identifier */
-	struct context context;	/* security context structure */
+struct sidtab_node
+{
+	u32 sid;
+	struct context* context;
 	struct sidtab_node *next;
 };
 
+
 #define SIDTAB_HASH_BITS 7
 #define SIDTAB_HASH_BUCKETS (1 << SIDTAB_HASH_BITS)
 #define SIDTAB_HASH_MASK (SIDTAB_HASH_BUCKETS-1)
@@ -30,28 +34,22 @@ struct sidtab {
 };
 
 int sidtab_init(struct sidtab *s);
-int sidtab_insert(struct sidtab *s, u32 sid, struct context *context);
-struct context *sidtab_search(struct sidtab *s, u32 sid);
+int sidtab_insert(struct sidtab *s, u32 sid,const struct context* context);
+const struct context* sidtab_search(struct sidtab *s, u32 sid);
 
-int sidtab_map(struct sidtab *s,
-	       int (*apply) (u32 sid,
-			     struct context *context,
-			     void *args),
-	       void *args);
 
 void sidtab_map_remove_on_error(struct sidtab *s,
 				int (*apply) (u32 sid,
-					      struct context *context,
+					      const struct context *context,
 					      void *args),
 				void *args);
 
 int sidtab_context_to_sid(struct sidtab *s,
-			  struct context *context,
+			  const struct context *context,
 			  u32 *sid);
 
 void sidtab_hash_eval(struct sidtab *h, char *tag);
 void sidtab_destroy(struct sidtab *s);
-void sidtab_set(struct sidtab *dst, struct sidtab *src);
 void sidtab_shutdown(struct sidtab *s);
 
 #endif	/* _SS_SIDTAB_H_ */

[RFC][PATCH 4/7] exports

[Török Edwin]

These symbols are exported, to be used by an iptables module.

---
 exports.c   |   33 +++++++++++++++++++++++++++++++++
 fireflier.h |    9 +++++++++
 2 files changed, 42 insertions(+)
diff -uprN null/exports.c fireflier_lsm/exports.c
--- null/exports.c	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/exports.c	2006-04-07 14:39:27.000000000 +0300
@@ -0,0 +1,33 @@
+#include "fireflier.h"
+#include "structures.h"
+#include "autolabel.h"
+#include <linux/socket.h>
+#include <net/sock.h>
+void fireflier_sk_ctxid(struct sock *sk,u32 *sid) 
+{
+	struct socket *sock;
+	sock = sk->sk_socket;
+	if (sock)
+	{
+		struct inode *inode;
+		inode = SOCK_INODE(sock);
+		if (inode)
+		{
+			struct fireflier_inode_security_struct *isec;
+			isec = inode->i_security;
+			if (sid && isec)
+				*sid = isec->sid;
+			//	     if (class)
+			//	       *class = isec->sclass;
+		}
+	}
+}
+
+int fireflier_available(void)
+{
+	return 1;
+}
+
+EXPORT_SYMBOL_GPL(fireflier_sk_ctxid);
+EXPORT_SYMBOL_GPL(fireflier_available);
+
diff -uprN null/fireflier.h fireflier_lsm/fireflier.h
--- null/fireflier.h	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/fireflier.h	2006-03-29 23:07:46.000000000 +0300
@@ -0,0 +1,9 @@
+#ifndef _FIREFLIER_H
+#define _FIREFLIER_H
+#include <linux/types.h>
+#include <linux/module.h>
+struct sock;
+void fireflier_sk_ctxid(struct sock *sk,u32 *ctxid);
+int fireflier_available(void);
+int fireflier_ctx_to_id(const char* dev,unsigned long inode,u32 *ctxid);
+#endif

[RFC][PATCH 5/7] debugging/testing support

[Török Edwin]

This dumps sid/pid maps to debugfs.
It is to be used for debugging/testing only.

---
 fireflier_debug.c |  134 
++++++++++++++++++++++++++++++++++++++++++++++++++++++
 fireflier_debug.h |   18 +++++++
 2 files changed, 152 insertions(+)
diff -uprN null/fireflier_debug.c fireflier_lsm/fireflier_debug.c
--- null/fireflier_debug.c	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/fireflier_debug.c	2006-03-29 23:23:57.000000000 +0300
@@ -0,0 +1,134 @@
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+
+#include "fireflier_debug.h"
+static struct dentry* fireflier_debugfs=0;
+static struct dentry* sidmap_debugfs=0;
+static struct dentry* pidmap_debugfs=0;
+
+extern int ff_debug;
+
+static int debug_show(struct seq_file *s, void *_)
+{
+	seq_printf(s,"%s\n",(char*)s->private);
+	return 0;
+}
+
+static int debug_string_open(struct inode* inode, struct file* file)
+{
+	return single_open(file,debug_show,inode->u.generic_ip);
+}
+
+
+static struct file_operations fops_string = {
+	.open           = debug_string_open,
+	.read           = seq_read,
+	.llseek         = seq_lseek,
+	.release        = single_release,
+};
+
+
+
+static inline struct dentry* debugfs_create_readonly_string(const char* 
name,mode_t mode,struct dentry* parent,char* value)
+{
+	return debugfs_create_file(name,mode,parent,value,&fops_string);
+}
+
+void ff_debug_map_pidsid(u32 sid)
+{
+	u32* sid_d = kmalloc(sizeof(u32),GFP_ATOMIC);
+	char pid_s[16];
+
+	if(unlikely(!ff_debug))
+		return;
+
+	if(unlikely(!sid_d)) {
+		printk(KERN_DEBUG "fireflier::ff_debug_map_pidsid: OOM\n");
+		return;
+	}
+	*sid_d = sid;
+	snprintf(pid_s,16,"%d",current->pid);
+
+	debugfs_create_u32(pid_s,0,pidmap_debugfs,sid_d);
+}
+
+void ff_debug_dump_sid(const struct context* context,u32 sid)
+{
+	struct
+	{
+
+		u32 inode;
+		u8  unsafe;
+		char mntpoint[];
+
+	}
+	* sid_debug = kmalloc( sizeof(*sid_debug)+strlen(context->mnt_devname)+1, 
GFP_ATOMIC);
+	//	u32* inode_d = kmalloc(sizeof(u32),GFP_ATOMIC);
+	char sid_s[16];
+	struct dentry* sid_dentry=NULL;
+	//	char* mntpoint_d = kmalloc(strlen(mntpoint)+1,GFP_ATOMIC);
+	//	strncpy(mntpoint_d,mntpoint,strlen(mntpoint)+1);
+
+	if(unlikely(!ff_debug))
+		return;
+
+	
strncpy(sid_debug->mntpoint,context->mnt_devname,strlen(context->mnt_devname)+1);
+	sid_debug->inode=context->inode;
+	sid_debug->unsafe=context->unsafe;
+
+	/*	if(unlikely(!inode_d)) {
+		printk(KERN_DEBUG "fireflier::ff_debug_dump_sid: OOM\n");
+		return;
+		}
+		*inode_d=inode;*/
+	snprintf(sid_s,16,"%d",sid);
+
+	sid_dentry = debugfs_create_dir(sid_s,sidmap_debugfs);
+	if(!sid_dentry) {
+		//already created
+		return;
+	}
+
+
+	debugfs_create_u32("inode",0,sid_dentry,&sid_debug->inode);
+	debugfs_create_u8("unsafe",0,sid_dentry,&sid_debug->unsafe);
+	
debugfs_create_readonly_string("mountpoint",0,sid_dentry,sid_debug->mntpoint);
+	if(context->groupmembers>0)
+	{
+		int i;
+		for(i=0;i<context->groupmembers;i++)
+		{
+			snprintf(sid_s,16,"%d",context->sids[i]);
+			debugfs_create_u8(sid_s,0,sid_dentry,&sid_debug->unsafe);
+		}
+	}
+}
+
+
+
+void ff_debug_startup(void)
+{
+	if(!ff_debug)
+		return;
+	ff_debug=0;
+	fireflier_debugfs = debugfs_create_dir("fireflier",NULL);
+	if(!fireflier_debugfs)  {
+		printk(KERN_DEBUG "fireflier: failed to create debug root fs!\n");
+		return;
+	}
+
+	sidmap_debugfs = debugfs_create_dir("sidmap",fireflier_debugfs);
+	if(!sidmap_debugfs) {
+		printk(KERN_DEBUG "fireflier: failed to create debug sidmap fs!\n");
+		return;
+	}
+
+	pidmap_debugfs = debugfs_create_dir("pidmap",fireflier_debugfs);
+	if(!pidmap_debugfs) {
+		printk(KERN_DEBUG "fireflier: failed to create debug sidmap fs!\n");
+		return;
+	}
+
+	ff_debug=1;
+	printk(KERN_DEBUG "fireflier: debugging enabled\n");
+}
diff -uprN null/fireflier_debug.h fireflier_lsm/fireflier_debug.h
--- null/fireflier_debug.h	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/fireflier_debug.h	2006-03-29 23:23:57.000000000 +0300
@@ -0,0 +1,18 @@
+#ifndef _FIREFLIER_DEBUG_H
+#define _FIREFLIER_DEBUG_H
+
+#define FIREFLIER_DEBUG 1
+#include "context.h"
+//extern struct dentry* fireflier_debugfs;
+
+#ifndef FIREFLIER_DEBUG
+static inline void ff_debug_dump_sid(const struct context* context,u32 sid) 
{}
+static inline void ff_debug_startup(void) {}
+static inline void ff_debug_map_pidsid(u32 sid) {}
+#else
+void ff_debug_dump_sid(const struct context* context,u32 sid);
+void ff_debug_startup(void);
+void ff_debug_map_pidsid(u32 sid);
+#endif
+
+#endif

[RFC][PATCH 6/7] userspace

[Török Edwin]

The makefile for the lsm module, and a test app I used to verify that 
getxattr() works properly with my lsm.

---
 Makefile         |   10 ++++++++++
 xattr_helper.cpp |   54 
++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff -uprN null/Makefile fireflier_lsm/Makefile
--- null/Makefile	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/Makefile	2006-04-07 15:08:00.000000000 +0300
@@ -0,0 +1,10 @@
+obj-m += fireflier.o
+fireflier-objs := hooks.o autolabel.o sidtab.o fireflier_debug.o
+KERN = $(shell uname -r)
+#KERN = 2.6.16.1
+all: 
+	make -C /lib/modules/$(KERN)/build M=$(PWD) modules
+
+clean:
+	make -C /lib/modules/$(KERN)/build M=$(PWD) clean
+      
diff -uprN null/xattr_helper.cpp fireflier_lsm/xattr_helper.cpp
--- null/xattr_helper.cpp	1970-01-01 02:00:00.000000000 +0200
+++ fireflier_lsm/xattr_helper.cpp	2006-04-07 18:06:38.000000000 +0300
@@ -0,0 +1,54 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <attr/xattr.h>
+
+void die(const char* msg)
+{
+
+   perror(msg);
+   exit(1);
+}
+
+void showArray(const char* array,ssize_t len)
+{
+   for(int i=0;i<len;i++)
+     if(array[i])
+       putchar(array[i]);
+   else putchar('\n');
+}
+
+int main(int argc,char* argv[])
+{
+
+   if(argc==2) 
+     {
+	const char* filename = argv[1];
+	ssize_t len = listxattr(filename,NULL,0);
+	if(len==-1)
+	  die("error getting list size");
+	char* list = new char[len+1];
+	if((len=listxattr(filename,list,len))==-1)
+	  die("error listing attributes names");
+	printf("List of security attributes:\n");
+	showArray(list,len);
+	delete[] list;
+     }
+   else if(argc==3) 
+     {
+	const char* filename = argv[1];
+	const char* name = argv[2];
+	ssize_t len = getxattr(filename,name,NULL,0);
+	if(len==-1)
+	  die("error getting xattr list size");
+	char* list = new char[len+1];
+	if((len = getxattr(filename,name,list,len))==-1)
+	  die("error getting xattr");
+	printf("xattr %s of %s is:",name,filename);
+	showArray(list,len);
+	delete[] list;
+     }
+   else
+     printf("Usage: %s filename [xattr_name]\n",argv[0]);   
+   return 0;
+}

[RFC][PATCH 7/7] stacking support for capability module

[Török Edwin]

Adds stacking support to capability module. Without this patch, I have to boot 
with capability.disable=1 to get fireflier registered as security module.

What is current status of stacking support, how should LSM's handle stacking 
with the capability module?


---
 capability.c |  114 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 commoncap.c  |   10 ++++-
 2 files changed, 123 insertions(+), 1 deletion(-)
diff -uprN -X vanilla/linux-2.6.16/Documentation/dontdiff 
vanilla/linux-2.6.16/security/capability.c linux-2.6.16/security/capability.c
--- vanilla/linux-2.6.16/security/capability.c	2006-03-20 18:29:57.000000000 
+0200
+++ linux-2.6.16/security/capability.c	2006-04-07 16:32:43.000000000 +0300
@@ -24,6 +24,104 @@
 #include <linux/ptrace.h>
 #include <linux/moduleparam.h>
 
+/* stacking support */
+struct security_operations *cap_original_ops = NULL;
+extern struct security_operations *cap_secondary_ops;
+
+int cap_stack_bprm_alloc_security(struct linux_binprm *bprm)
+{
+  return cap_secondary_ops->bprm_alloc_security(bprm);
+}
+
+void cap_stack_bprm_free_security(struct linux_binprm *bprm)
+{  	
+  return cap_secondary_ops->bprm_free_security(bprm);
+}
+
+void cap_stack_bprm_post_apply_creds(struct linux_binprm *bprm)
+{
+  return cap_secondary_ops->bprm_post_apply_creds(bprm);
+}
+void cap_stack_inode_free_security(struct inode *inode)
+{
+  return cap_secondary_ops->inode_free_security(inode);
+}
+
+int cap_stack_inode_getsecurity(struct inode *inode, const char *name, void 
*buffer, size_t size, int err)
+{
+  return cap_secondary_ops->inode_getsecurity(inode,name,buffer,size,err);
+}
+
+int cap_stack_inode_listsecurity(struct inode *inode, char *buffer, size_t 
buffer_size)
+{
+  return cap_secondary_ops->inode_listsecurity(inode,buffer,buffer_size);
+}
+
+
+int cap_stack_file_receive(struct file* file)
+{
+  return cap_secondary_ops->file_receive(file);
+}
+
+int cap_stack_task_alloc_security(struct task_struct *task)
+{
+   if(cap_secondary_ops)
+     return cap_secondary_ops->task_alloc_security(task);
+   else return 0;
+}
+
+void cap_stack_task_free_security(struct task_struct *task)
+{
+  return cap_secondary_ops->task_free_security(task);
+}
+
+void cap_stack_socket_post_create(struct socket *sock, int family,
+					 int type, int protocol, int kern)
+{
+  return 
cap_secondary_ops->socket_post_create(sock,family,type,protocol,kern);
+}
+
+int cap_stack_socket_accept(struct socket *sock, struct socket *newsock)
+{
+  return cap_secondary_ops->socket_accept(sock,newsock);
+}
+
+
+
+int cap_stack_register_security (const char *name, struct security_operations 
*ops)
+{
+	if (cap_secondary_ops != cap_original_ops)
+	{
+		printk(KERN_INFO "%s:  There is already a secondary security "
+		       "module registered.\n", __FUNCTION__);
+		return -EINVAL;
+	}
+	
+	cap_secondary_ops = ops;
+	
+	printk(KERN_INFO "%s:  Registering secondary module %s\n",
+	       __FUNCTION__,
+	       name);
+	
+	return 0;
+}
+
+static int cap_stack_unregister_security (const char *name, struct 
security_operations *ops)
+{
+        if (ops != cap_secondary_ops)
+        {
+                printk (KERN_INFO "%s:  trying to unregister a security 
module "
+                        "that is not registered.\n", __FUNCTION__);
+                return -EINVAL;
+        }
+
+        cap_secondary_ops = cap_original_ops;
+
+        return 0;
+}
+
+
+
 static struct security_operations capability_ops = {
 	.ptrace =			cap_ptrace,
 	.capget =			cap_capget,
@@ -47,6 +145,20 @@ static struct security_operations capabi
 	.syslog =                       cap_syslog,
 
 	.vm_enough_memory =             cap_vm_enough_memory,
+	/* for stacking */
+	.bprm_alloc_security  	= cap_stack_bprm_alloc_security,
+	.bprm_free_security  	= cap_stack_bprm_free_security,
+	.bprm_post_apply_creds  = cap_stack_bprm_post_apply_creds,
+	.inode_free_security 	= cap_stack_inode_free_security,
+    	.inode_getsecurity 	= cap_stack_inode_getsecurity,
+   	.inode_listsecurity 	= cap_stack_inode_listsecurity,
+	.file_receive 		= cap_stack_file_receive,
+	.task_alloc_security 	= cap_stack_task_alloc_security,
+	.task_free_security 	= cap_stack_task_free_security,
+	.socket_post_create 	= cap_stack_socket_post_create,
+	.socket_accept 		= cap_stack_socket_accept,
+	.register_security 	= cap_stack_register_security,
+	.unregister_security 	= cap_stack_unregister_security,
 };
 
 /* flag to keep track of how we were registered */
@@ -58,6 +170,7 @@ MODULE_PARM_DESC(disable, "To disable ca
 
 static int __init capability_init (void)
 {
+        cap_original_ops = cap_secondary_ops = security_ops;
 	if (capability_disable) {
 		printk(KERN_INFO "Capabilities disabled at initialization\n");
 		return 0;
@@ -100,3 +213,4 @@ module_exit (capability_exit);
 
 MODULE_DESCRIPTION("Standard Linux Capabilities Security Module");
 MODULE_LICENSE("GPL");
+
diff -uprN -X vanilla/linux-2.6.16/Documentation/dontdiff 
vanilla/linux-2.6.16/security/commoncap.c linux-2.6.16/security/commoncap.c
--- vanilla/linux-2.6.16/security/commoncap.c	2006-03-20 18:29:57.000000000 
+0200
+++ linux-2.6.16/security/commoncap.c	2006-04-07 15:48:21.000000000 +0300
@@ -25,6 +25,9 @@
 #include <linux/xattr.h>
 #include <linux/hugetlb.h>
 
+
+struct security_operations *cap_secondary_ops = NULL;
+
 int cap_netlink_send(struct sock *sk, struct sk_buff *skb)
 {
 	NETLINK_CB(skb).eff_cap = current->cap_effective;
@@ -135,7 +138,9 @@ int cap_bprm_set_security (struct linux_
 		if (bprm->e_uid == 0)
 			cap_set_full (bprm->cap_effective);
 	}
-	return 0;
+       if(cap_secondary_ops)
+	return cap_secondary_ops->bprm_set_security(bprm);
+       else return 0;
 }
 
 void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
@@ -179,6 +184,8 @@ void cap_bprm_apply_creds (struct linux_
 	/* AUD: Audit candidate if current->cap_effective is set */
 
 	current->keep_capabilities = 0;
+        if(cap_secondary_ops)
+          cap_secondary_ops->bprm_apply_creds(bprm,unsafe);
 }
 
 int cap_bprm_secureexec (struct linux_binprm *bprm)
@@ -341,6 +349,7 @@ EXPORT_SYMBOL(cap_task_post_setuid);
 EXPORT_SYMBOL(cap_task_reparent_to_init);
 EXPORT_SYMBOL(cap_syslog);
 EXPORT_SYMBOL(cap_vm_enough_memory);
+EXPORT_SYMBOL(cap_secondary_ops);
 
 MODULE_DESCRIPTION("Standard Linux Common Capabilities Security Module");
 MODULE_LICENSE("GPL");

Re: [RFC][PATCH 7/7] stacking support for capability module

[Serge E. Hallyn]

Quoting T??r??k Edwin (edwin@gurde.com):
> Adds stacking support to capability module. Without this patch, I have to boot 
> with capability.disable=1 to get fireflier registered as security module.
> 
> What is current status of stacking support, how should LSM's handle stacking 
> with the capability module?

For now, pretty much like this.

The lsm stacker is still being kept up to date at
www.sf.net/projects/lsm-stacker.

-serge

Re: [RFC][PATCH 0/7] fireflier LSM for labeling sockets based on its creator (owner)

[Chris Wright]

* Török Edwin (edwin@gurde.com) wrote:
> The purpose of the fireflier LSM is to "label" each socket with a context, 
> where the context is a (list of) the program(s) that has/have access to it.
> 
> I've written fireflier LSM to allow filtering packets "per application". It is 
> meant to be used only when SELinux is not available (not available/disabled 
> at boot). For more details, see the initial discussion [1]

There is so much SELinux code in here, it's really not making sense to
do this as separate work.

> Summary of how fireflier LSM works:
> - each program is associated a sid, depending on its mountpoint+inode, i.e. 2 
> processes launched from the same program have the same sid

That sounds like a problem.  Ptrace can undermine that really easily.
Also bind mounts will give you a different sid for same exectuable, with
a possible way to get into interesting 'group' situation.
 
> - each socket created by a processis labeled with the process's sid
> - if 2 or more programs have access to the socket, it is labeled with a "group 
> sid". A group sid contains a list of the sids of programs having access
> - userspace, or iptables module can match packets on this "fireflier context"

How do you keep from joining the group?

> As I stated in my previous mail, I intend to write a userspace policy module 
> generator, that is to be used when selinux is enabled.
> When it is disabled, then only would the fireflier lsm be used.
> 
> I am asking for your comments/suggestions on the following issues:
> - security/correctness of the LSM (is there a way for a program to have access 
> to a socket, and escaping the labeling?)

what do you do about ptrace, /proc/[pid]/mem, fd passing, bind mounts, /proc/self/mem, etc.

> - how do I generate an SELinux policy, that does what this LSM module does?

Sounds like the best solution.

thanks,
-chris

Re: [RFC][PATCH 0/7] fireflier LSM for labeling sockets based on its creator (owner)

[edwin]

On Fri, Apr 07, 2006 at 12:45:45PM -0700, Chris Wright wrote:
> 
> > Summary of how fireflier LSM works:
> > - each program is associated a sid, depending on its mountpoint+inode, i.e. 2 
> > processes launched from the same program have the same sid
> 
> That sounds like a problem.  Ptrace can undermine that really easily.
I forgot to mention, if a process gets ptraced, it is getting a different sid.
> Also bind mounts will give you a different sid for same exectuable, with
> a possible way to get into interesting 'group' situation.
I should use something else instead of the mountpoint to make sure inodes are unique.
Maybe I should use the device, instead of the mountpoint.
>  
> > - each socket created by a processis labeled with the process's sid
> > - if 2 or more programs have access to the socket, it is labeled with a "group 
> > sid". A group sid contains a list of the sids of programs having access
> > - userspace, or iptables module can match packets on this "fireflier context"
> 
> How do you keep from joining the group?
New processes aren't added to a group, instead a new group is created.
So if A, and B are in group 1; and C would have to be added, then a new group (2) is created, that
contains all what the previous contained (A,B), and the newly added sid (C)
When you create rules for group A, and B; any socket labeled with that group sid will be accessed only by A and B.

> what do you do about ptrace,
As stated above, ptracing means a new sid (I used the unsafe flag passed to certain function by the kernel, maybe I
should also implement the ptrace hook)
 /proc/[pid]/mem, 
Restricting access to /proc/[pid]/mem can be done properly by SELinux.
Is it worth to implement access restriction to /proc/self/mem in fireflier lsm?
If so, should I restrict access to it for all programs except the process itself?
> fd passing,
 I implemented the file_receive hook. Is there any other way to pass a fd? (besides fork+execve which is covered)
>  bind mounts,
using the device instead of mountpoint? But are devices named consistently between boots? what if somebody adds/removes
a harddisk/usb stick? will that change the device naming? 
> /proc/self/mem,
Why is this a security risk? Can a child process access the parent's data through /proc/self/mem?
> etc.
You made me curious, what other ways are there to gain access to the "data" and open files held by another process?
(Of course if somebody wants "full" security, he should use SELinux.)
> 
> > - how do I generate an SELinux policy, that does what this LSM module does?
> 
> Sounds like the best solution.
Yes, but writing such a policy will take time, that is why it is planned for version 2.1, or 2.2.
I will try to write a policy module generator userspace program, but I don't know how to create
"group labels". How do I label a socket, in such a way, that I'll be able to determine all the programs having access
to it? Can an inode have multiple labels (contexts)?

Having a fireflier lsm in 2.0 (although with reduced security compared to SELinux) is better than having no lsm at all.
FYI fireflier 1.x, and 1.99beta accepted a packet if the first (!) program found to have access to a socket was
 in its list of rules. (finding this was done searching /proc for an open socket having the proper inode, 
 determined from /proc/net/tcp|udp|tcp6|udp6)


Thanks in advance,
Edwin

Re: [RFC] packet/socket owner match (fireflier) using skfilter

[Mikado]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Does your module get into below problem?

http://lkml.org/lkml/2006/4/20/132
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFESPmnNWc9T2Wr2JcRAnMtAKDZvLH2MRmY/jeW/YW/9UP1fm/xwgCfSZZ/
Qom6TxVirR4HWV9Asc2ZixY=
=xlSu
-----END PGP SIGNATURE-----

Re: [RFC] packet/socket owner match (fireflier) using skfilter

[Török Edwin]

On Friday 21 April 2006 18:26, Mikado wrote:
> Does your module get into below problem?
>
> http://lkml.org/lkml/2006/4/20/132
Nope.

A short test:
On host:
sudo iptables -A INPUT -p tcp --dport 81 -j DROP
In qemu:
#iptables -t skfilter -A OUTPUT -m fireflier_match --inode-owner 
24392 --dev-owner /dev/root -j LOG --log-prefix test_out2
#netcat 172.20.0.1 81
[4295327.547000] test_out2:IN= OUT=eth0 SRC=172.20.0.10 DST=172.20.0.1 LEN=60 
TOS=0x00 PREC=0x00 TTL=64 ID=11865 DF PROTO=TCP SPT=34945 DPT=81 WINDOW=5840 
RES=0x00 SYN URGP=0
[4295327.549000] test_out2:IN= OUT=eth0 SRC=172.20.0.10 DST=172.20.0.1 LEN=60 
TOS=0x00 PREC=0x00 TTL=64 ID=11865 DF PROTO=TCP SPT=34945 DPT=81 WINDOW=5840 
RES=0x00 SYN URGP=0
[4295330.550000] test_out2:IN= OUT=eth0 SRC=172.20.0.10 DST=172.20.0.1 LEN=60 
TOS=0x00 PREC=0x00 TTL=64 ID=11866 DF PROTO=TCP SPT=34945 DPT=81 WINDOW=5840 
RES=0x00 SYN URGP=0

As you can see several packets are sent out, and each one is matched (24392 is 
the inode of netcat here). 

Please note that using fireflier LSM is not recomended, as I am working on 
writing SELinux policies that do the same (fireflier LSM is itself using code 
from hooks.c from selinux). 
See: http://lkml.org/lkml/2006/4/17/81


Also take a look at James Morris's skfilter patches (which are used in 
fireflier too), they allow you to match at socket level, and also allow to 
match based on selinux context.

Cheers,
Edwin