The AppArmor developer has been posting patches for review -- there's 
nothing stopping the code being merged except for the need to address 
purely technical issues raised by reviewers, which is ongoing.


Hey, thanks for another random unfounded personal attack, it's really 
appreciated.


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

[ message continues ]

It really isn't personal, you know. I don't even remember _who_ it was 
that thought that pathname-based security was fundamentally wrong and was 
bad-mouthing apparmor all they could. My point was just that there's a lot 
of mindless "my way or the highway" in some security circles, and apparmor 
really has been ridiculed.

It's not _that_ long ago that some group was trying to get rid of LSM just 
because "selinux is the only valid model".

		Linus
--

[ message continues ]

.. and perhaps more fundamentally, the deeper point was that that in no 
way stops the "upstream first" policy. Some Ubuntu people who wanted to 
get it merged were in fact worried that it might.

			Linus
--

[ message continues ]

Btw., now that we are a few reasonable months after the last big security 
flamewar it would be nice to see a rehash or fair summary of the pathname 
versus labels arguments. That particular issue does seem to be largely 
technical and thus we ought to be able to judge it one way or another.

IMO the main challenge in Linux security is to find and engage the right 
critical mass of developers to truly increase the security of 'Linux' as a 
whole in the long run.

That means, almost by definition, that we do not start by trying to create an 
'as secure as possible' system in the short run. Increased security is the 
_end goal_, not the means. I.e. we need a technology _process_ that results in 
more secure Linux systems.

( Trying to create an 'as secure as possible' system will almost certainly 
  backfire, as it results in _fewer_ developers/users caring. )

In that sense it appears to me that it's pretty much a universal truth that 
'pathnames' are a far more fitting abstraction to any 'human based security 
process' on Linux than 'labels'. (It does not matter at all that security 
research suggest that the most secure systems are label based and that there 
are some hard problems with pathname based approaches such as hardlinks, 
--bind mounts, etc.)

So here i see somewhat of a conceptual failure of SELinux that would be nice 
to see fixed: inherent hostility against pathname based approaches, just 
because they are technically less secure.

To me the relabeling performance problem and the fact that selinux labels are 
physically attached to the objects themselves is a potentially bigger 
'security problem' than the racy nature (and aliasing/ambiguity problems) of 
VFS pathname based security is.

In other words: i see selinux's main failure in that it somewhat blindly aims 
for a security model that it sees as the technicaly most secure, while not 
being intellectually open to the fact that we very likely _cannot know in 
advance_ which of the models will make ...
[ message continues ]

Ingo - just about all the serious security work disagrees with you.
Pathnames are references to objects and keep changing. What matters is
the object itself. This is also how Unix has always worked


I don't believe it was. It was perceived as a technical failure, and then
the file system people shredded the bits the security folks didn't.

There are certain things path name bases security works quite nicely for,
primarily systems that have no concept of links. It's why it works
ok-ish for httpd but for the general case nobody has ever really made it
work properly.

Alan
--

[ message continues ]

The thing is, that's simply not the whole truth. It's _part_ of the truth, 
but there very much are pathname-based security in Unix too, including 
very much traditionally.

Things like "/etc/passwd" really are about the _pathname_, not the inode. 
It really is the _path_ that is special, because that is fundamentally the 
thing you trust.

You can try to turn that into a content-based security issue by claiming 
that it's about the "content of the '/etc' directory", and that is (along 
with other tricks) obviously how a a content-based security model has to 
work.

But it's not actually _true_ in any deeper sense. You're really just 
trying to enforce a pathname-based model using a inode/content based 
security hammer.

So that's an example of "if all you have is a hammer, everything looks 
like a nail" issue. If all you have is a content/inode-based security, you 
have to turn path-names into "directory inode" issues, and it's doable, 
but it's really like trying to convince everybody that screws do not exist 
because all you have is a hammer.

And when you base your security on inodes, you _do_ have problems with 
things like /etc. Exactly because there are many different paths in that 
directory, and they actually have _different_ security issues. A program 
that is supposed to be able to edit/replace /etc/hosts is _not_ supposed 
to be able to edit/replace /etc/passwd.

Notice how it's really fundamentally about the pathname? When you create a 
new file and overwrite /etc/passwd with that file, the security rules 
really do _not_ come from your newly created inode, they come from the 
fact that you made the path "/etc/passwd" point to that inode.

And again - you can emulate this with the inode-based thing. Your hammer 
does work, but it doesn't really invalidate the fact that the path really 
is what is most fundamental in that case, because the pathname is 
fundamentally the shared piece of information that different processes 
work with.

You end up making ...
[ message continues ]

Because you don't have to use that pathname to modify the bits returned
by read() after open() on that pathname?

I'm not fond of selinux, to put it mildly, but "pathname-based" stuff simply
doesn't match how the pathname resolution is defined on Unix...
--

[ message continues ]

PS: at that point the *only* things I care about wrt "security" junk are
	* it shouldn't create new assertions to keep for VFS and fs code
	* it shouldn't break the normal Unix permissions for boxen that
sanely have all that crap disabled
	* it shouldn't make one vomit just from RTFS
	* it shouldn't create obvious rootholes when enabled
	* it shouldn't add overhead from hell
	* it shouldn't try to hide the violations of the conditions above

My opinion of the "security community" is worse than yours, BTW.  You have
decided that to let their stuff in; IMO it had been a mistake from the very
beginning, but that's your tree.
--

[ message continues ]

The thing is, I don't think it's an "either or".

Sure, there is content security. Nobody disputes that. The security 
decision about how to open a file is about the contents of the file.

So I'm not suggesting we _replace_ content-based security with 
pathname-based security. I'm just saying that pathnames actually do matter 

Again, I'm not claiming that we should change how "open" works and has 
always worked. I don't even understand why you have that crazy "either or" 
mentality to begin with. Why?

It's not "either pathname or inode". I'm saying _both_ make sense. 

In some situations, the name itself really is what is fundamentally 
special about the file.

		Linus
--

[ message continues ]

Btw, I would also say that content security is generally the _common_ 
case. So I'm not at all saying that the traditional unix model or the 
selinux model is in any way "wrong". Not at all.

It's just that I certainly understand why some people think AppArmor is 
more "intuitive". And I think it's directly related to the fact that 
sometimes the pathname-based approach is the one that more directly 
reflects the particular issue (and people are often happy with the 
traditional UNIX semantics for plain inode-based security, so again, it's 
not like AppArmor _replaces_ inode-based security, it _extends_ on it).

			Linus


--

[ message continues ]

SELinux uses both. Things like "I put a file in my public_html directory"
are a good example.

Its object based in the sense that the origin of the data might matter
(eg 'no app which opens the credit card db creates a file httpd can send')

Its path based in the sense that public_html has a path based meaning by
convention understood by httpd. Copy a jpeg into your public_html and it
will be labelled up for http access under the Fedora shipped rule sets.

Alan

--

[ message continues ]

Umm. That was my point all along: you can basically "emulate" pathname 
based decisions by labeling things. But it's not always the most direct 
approach, and some people clearly do find AppArmor (or Tomoyo, which I 
think is also largely based on pathnames) to be more "intuitive".

So I don't understand it when people then complain about a mechanism that 
base their decisions fundamentally on the pathname. It's not like AppArmor 
got rid of the traditional unix inode-based protections and replaced them 
(like your silly DEC10 example).

But whatever. The fact is, Ubuntu uses it. We'll merge it.

				Linus
--

[ message continues ]

I'd be ever so thrilled if you'd merge utrace in that case...

cheers, Kyle
--

[ message continues ]

And mapping from names to files is a function of contents of many objects.
You need to protect that contents on all objects involved *anyway*.  Which
leaves what for "protecting by pathname"?

I'm not saying that it's either or.  I am saying that it's been oversold
to hell and back, BTW, but that's a separate story.  And I'm very sceptical
about separate protection of different directory entries, which is *all*
that is left for pathname-based stuff, AFAICS.
--

[ message continues ]

I think the point is actually that, ideally, content-based security is
for _reads_, while path-based security is for _writes_:

For example, in the /etc/shadow case:
1. Unprivileged users must not be able to know the _content_ of the
file (or of any copy of it)
2. It doesn't matter at all if anyone modifies a private copy of the
file (with the same content, but not the same path)
3. Unprivileged users must not change the data the /etc/shadow _path_
is associated with
4. It doesn't matter at all if anyone reads a file that happens to be
at /etc/shadow while not containing shadow passwords (with the same
path, but different content)

So I think we should enforce label/inode-based content security on
reads, but we should enforce path/dentry-based security on writes.

In particular, doing a write on a file, and moving a file to that same
path ought to have exactly the same security checks, since the
user-visible effect is the same.

The unix model is broken regarding this, since one will depend on the
write permissions on the file inode, and the other on the directory.
Ideally, both should depend on the write permissions of the _dentry_
(there would need to be a concept of default dentry permissions for a
directory).

The only thing that breaks this are hard links, since they allow to
change the data associated with multiple unknown dentries in a single
operation. However, completely disallowing writes to inodes with
multiple links solves the problem, and shouldn't require fundamental
(or any) userspace changes (of course, this is to be done by the
security module, not by the generic vfs).
--

[ message continues ]

What the hell are you smoking?
--

[ message continues ]

I mean, what is interesting for security of reading is the fact that
the file contains shadow passwords (and thus is labeled as "secret" or
with a specific label), not that it is at /etc/shadow.

The same security check would need to apply to an administrator's
backup copy of /etc/shadow, but would not need to apply in the
hypotetical case that /etc/shadow did not contain shadow passwords,
but, say, was empty or contained a pointer to a network server to use.

This is to illustrate the point, not something expected to happen; it
also represents the ideal security model, not necessarily any concrete
one.

So what really is interesting for reads is what the content is (in
practice, what the content label is), not the path.

For writes, it is exactly the opposite: you don't care about writing
to a private copy, but you don't want to let a random file be put on a
system path.
For instance, if I copy /etc/passwd somewhere else, the result should
have the same content label (since it is identical), but I should now
be able to write to it since the path allows me to.
--

[ message continues ]

<sarcasm>
Yeah, especially when it's read by sshd.  Who cares, indeed?  So it's got
a passwordless root, that's even better, right?  Nobody will see your
real root password that way...
</sarcasm>
--

[ message continues ]

Not sure what you mean exactly.
You won't have a passwordless root if you don't allow anyone to modify
the file at /etc/shadow, or change that dentry by deleting a file
there or putting an arbitrary file there (with creat, rename or link).
This is conceptually a path-based security check.

It is also separate from the problem of not giving anyone knowledge of
the root password or hash of it, which a conceptually content-based
security check on reads.
--

[ message continues ]

Quite untrue. I've actually *used* path based security systems (DEC10
ACLs) and for almost every case its brain-dead.

Imagine a world where this happened

	echo "hello" > fred
	chmod 666 fred
	ls -l fred
	fred rw-rw-rw-
	mv fred bill
	ls -l bill
	bill rw-------

week later
	vi fred
	ls -l fred
	fred rw-rw-rw-


In a secure system I don't just care if its called /etc/passwd. I care
that whoever made changes to it was trusted to do so and furthermore that
the suid binary, the libraries it relies upon and the other points of
trust that matter. Real security is *not* a file permissions system its a
trust model including things like integrity validation.

Another reason this is true is how passwd is updated - the tool creates
a new file of some name like passwd.tmp and does processing into that,
then renames it over the top. If I break passwd.tmp then you'll trust the
result "because it's called passwd", while a system that keeps
permissions and labels attached to the object will not because someone

No - they come from whatever created or modified the file. It doesn't
matter what an object is called if I need to know whether the data in it

The directory bits move with the directory - they are object
permissions to retrofit delete permission (a gap in the original
Unix design) and a very crude inheritance hack.

They are not about paths. If you mv a file into a directory with these

Perhaps because
- They understand what they are talking about and have studied the
  research
- They've got a grasp of the mathematical/logical models that this is all
  based upon
- They know the difference between access control lists and security
  models
- They aren't so arrogant as to assume that using the capslock key
  overrides fifty years of research

??

Alan
--

[ message continues ]

Alan, stop right there.

You're making the same silly and incorrect mistake that Al did.

Namely thinking that you have to have just one or the other.

When you say "your /etc/passwd example is a special case", you are 
admitting that there are two different cases, but then after that,  you 
still don't see the whole point I'm trying to make.

Let me try again:

  THERE ARE DIFFERENT CASES

That's the point. Just admit that, and then let the calm of "Ooh, there 
are different kinds of circumstances that may want different kinds of 
rules" permeate you.

My whole (and only) argument is against the "only one way is correct" 
mentality.

			Linus
--

[ message continues ]

I know. I also sometimes sit through minutes of "let's relabel the system, 
because you've booted a kernel without selinux support".

			Linus
--

[ message continues ]

I've had selinux relabeling wait times of an hour or two too, on a 
sufficiently large filesystem.

I think this hurts security far more than anything else, because it causes 
people to actually _turn off the whole thing_ - so we will have less and less 
security in the end.

( To use the obligatory fire door analogy: we should prefer a one inch thick 
  fire door that opens and closes fully automated to a five inches thick fire 
  door that people keep always-open with a chair. )

	Ingo
--

[ message continues ]

selinux relabels are the new fsck.

maybe we need selinux3 or chunk-selinux.

Dave.
--

[ message continues ]

Once the fanotify stuff is in (or however it'll be called) the new
relabel process could temporarily install itself to intercept all
filesystem operations and fix up files on demand while going along
it's normal operation in the background.  No reason to stall the
system completely.

If this is the biggest complaint then you should be supportive of the approach.
--

[ message continues ]

man restorecond

I don't think the SELinux folks would or could deny that case existed...

Alan
--

[ message continues ]

Reading through all of this it occurred to me there is a case where
path names are fundamentally important shows up for me all of the
time.  If pathnames were not fundamentally important we could apply
a patch like the one below and allow unprivileged users to unshare
the mount namespace and mount filesystems wherever.  There is nothing
fundamental about those operations that require root privileges except
that you are manipulating the pathnames of objects.

Unfortunately if we did that suid executables would become impossible
because they couldn't trust anything to start with.

Even little things like /lib64/ld-linux-x86-64.so are very special things
that you can't let just anyone change.

Eric


diff --git a/fs/namespace.c b/fs/namespace.c
index d69c06f..85ba785 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1650,10 +1650,6 @@ static int do_new_mount(struct path *path, char *type, int flags,
 	if (!type)
 		return -EINVAL;
 
-	/* we need capabilities... */
-	if (!capable(CAP_SYS_ADMIN))
-		return -EPERM;
-
 	lock_kernel();
 	mnt = do_kern_mount(type, flags, name, data);
 	unlock_kernel();
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
index 1e8cda0..00fd7c5 100644
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -180,9 +180,6 @@ int unshare_nsproxy_namespaces(unsigned long unshare_flags,
 			       CLONE_NEWNET | CLONE_NEWPID)))
 		return 0;
 
-	if (!capable(CAP_SYS_ADMIN))
-		return -EPERM;
-
 	*new_nsp = create_new_namespaces(unshare_flags, current,
 				new_fs ? new_fs : current->fs);
 	if (IS_ERR(*new_nsp)) {

--

[ message continues ]

You do realize that with content based security systems the pathnames
aren't important and you could implement your example patch?  Sure a
user could mount something on /lib and put their own files there, but
since that user couldn't get them labelled correctly the suid app
would not be able to use them and would fail.  Users would have new
and interesting way to break their computers!  I thank you for your
vote for content based security systems instead of pathname systems
and look forward to your future contributions to either that body of
knowledge or the bridging of the gap between the two *smile*

-Eric
--

[ message continues ]

On Mon, 8 Mar 2010 18:18:21 -0500

but isn't that why a pathname based protect of /lib would be better? so

i interpret it not this way. but i'm an amateur securita :)

cheers,
Flo


--

[ message continues ]

And in a purely SELinux enviromnment your patch would work out because

It does raise the question about whether you can do it if you had a
namespace property of "ignore suidness". I'm not sure thats enough
however.
--

[ message continues ]

Weird.  Somehow I only got a copy of this from lkml.


The long term plan is to change that to.

	if (nscapable(mnt_ns->user_ns, CAP_SYS_ADMIN))
		return -EPERM.

That is.
- Create a new user/credential namespace (ultimately an unprivileged operation).
- Have the root user of the new user namespace create a new mount namespace.
- Over that new mount namespace the root user of the new user namespace
  has full control.

It is a little convoluted but it maintains backwards compatibility.  Unfortunately
there is still a long ways to go before we get there.

Eric
--

[ message continues ]

On Mon, Mar 8, 2010 at 10:08, Linus Torvalds

This is not a fundamental problem.  It's rather a detail of the
current policies and legacy apps.

I think I would like to see /etc/passwd to also get a file type like
/etc/shadow.  This is I think today not done because of the work
involved and the perceived lower severity because passwords are in
/etc/shadow.

So let's talk about /etc/shadow.  If somehow the file is removed and
somebody creates a new file that file won't automatically get the
right label.  This means that code reading the file then could be
prevented from doing this with appropriate policy rules.  Here the
filename is not sufficient for access.  You also need the label and
that you won't get without subverting the system.  With filename based
mechanisms this isn't the case: once the file is compromised the
attack succeeded.

Yes, the current situation isn't optimal.  We have to make the
policies more complicated and we have to get rid of restorecond (at
least for most cases).  But there is no fundamental problem with
labels while filename-based mechanisms provide no security
improvement.
--

[ message continues ]

At the moment the default label of a new file is created based on the
label of the creating process and the label of the parent directory.
It's certainly not impossible that a third factor could be added 'the
last component of the pathname of the new inode' to the decision
matrix.  Doing so would eliminate the need for restorecond in most (or
maybe all) situations while maintaining the useful security principles
of label based enforcement.  It actually has been suggested and
implemented, but as I recall we were told it violated some VFS rules
to pass the information we passed where we passed it and it was
abandoned.

*tongue in cheek* if TOMOYO and AppArmour can do thing which the VFS
maintainer say is wrong and unacceptable merely by sending them to the
security maintainer instead I guess SELinux can do that as well!

answering a different post in the same email: I accept "THERE ARE
DIFFERENT CASES."  You go on to say "So I'm not suggesting we
_replace_ content-based security with pathname-based security. I'm
just saying that pathnames actually do matter for security, and that
they are an independent issue."  But what you are suggesting is
EXACTLY that our users should _replace_ content-based security with
pathname-based security when they have to boot with security=TOMOYO
instead of security=SMACK.  Rather than finding a flexible framework,
finding problems or inadequacies in that framework, and solving those
problems you instead force our users to have to choose between LSMs
which are either A) secueable but non-intuitive or B) not securable
but known to be 'easier'.

I think the inode based security view as a hammer might not be all
that bad.  It works really well on nails (you know the truely hard
well researched security questions) and it can beat screws into a
piece of wood as well (although sometimes the wood cracks).  Calling
pathname based security a screwdriver fits too, it can put the screws
in but we know there are a lot of nails out there which it can't ...
[ message continues ]

No.

Because we already _have_ content-based security. The traditional UNIX 
model is all about "labeling", ie the inode-based security.

The fact that the extended security is then using something else in Tomoyo 
or AppArmor doesn't remove the traditional security model.

Again, your whole email is just "assuming" that selinux is the thing to 
be. No logic to your post at all. If you are using a AppArmor-based thing, 
you're not "switching" from SELinux to AppArmor. You're just using it.

Get it? The Ubuntu people seem to be happy with AppArmor. Deal with it. 
SELinux isn't the end-all and be-all of everything.

			Linus
--

[ message continues ]

On the other hand, '/etc/shadow' has the opposite constraint,
where the system will not trust most of the applications with
the data from that file.

Using label security to protect the contents makes sense there.

Your example appears to be about "can the application trust
the data?", while the label based security solves "can the
application be trusted with the data?"

These are two different things.
--

[ message continues ]

Umm. No.

/etc/shadow is in no way at all different from /etc/passwd. Both of them 
have pathname-based security issues. The fact that both of them _also_ 
have content-based security issues is an independent issue that I just 
assumed everybody would take for granted.

Clearly I assumed too much.

So I was assuming that everybody realized that the normal inode-based UNIX 
security obviously means that you can only open /etc/passwd read-only as 
any normal user (and not open /etc/shadow at all: but that is in _no_ way 
different from /etc/passwd).

That's an example of non-pathname-based security, where you actually mark 
the content itself restricted some way. It's very naturally done with 
labels on the inode itself. It's what UNIX has _always_ done

Nobody has ever suggested removing that. That would be crazy.

But that thing is _independent_ from the other totally unrelated issue, 
namely the fact that "/etc/passwd" is a special name in the namespace. In 
other words, there is "content security", but then there is also 
"namespace security". 

Of course, you can make /etc unwritable, and that is indeed the 
traditional UNIX model of handling namespace security: by just 
implementing it as "content security" of the directory.

The sgid and sticky bits can be used to further try to make it more 
fine-grained (exactly becuase it is _not_ sufficient to say "you can't 
read or write this directory" on a whole-directory basis), and obviously 
SELinux has extensions of its own too.

Can you really not see the difference between security of naming thigns 
certain things (like "/etc/passwd") - pathname based issues - and the 
separate security of limiting access to any named device - actual markings 
on the inode itself?

				Linus
--

[ message continues ]

It is quite clear that the content based security
protects the content from being manipulated by
processes that should not be able to do so.


... what exactly does the namespace security protect against?

What is the threat model that the namespace security protects
against, which is not protected by the content based security?

--

[ message continues ]

Umm? Seriously? 

What is _any_ security all about? You try to limit the opportunity for 
damage, accidental or not.

So let's take a trivial example. Let's say that you are root, and you edit 
/etc/shadow by hand. I've done it, you've probably done it, it's not 
rocket science. Now, you do it using any random editor, and most likely 
it's going to write the new file into a temp-file, and then rename that 
temp-file over the old file (perhaps creating a backup of the old file 
depending on editor and settings).

Now, think about what that implies for a moment. Especially consider the 
case that there were ACL's ("inode-based security") on the old /etc/passwd 
or /etc/shadow file that got moved away as a backup. What happened to 
those ACL's when you edited the file using a random editor?

Now, do you see what the difference between pathname-based and inode-based 
security is? Do you realize how if anybody wants to track accesses to 
/etc/shadow, they are not going to be interested in the _old_ backup copy 
of /etc/shadow?

				Linus
--

[ message continues ]

And if you really want to get down to brass tacks it wouldn't hurt
if either camp dusted off their faded copy of the DoD Orange Book
and read a few verses. The access control requirements are stated
in terms of objects but the audit requirements clearly want pathnames.
The security modelers were nuts to protect objects (inodes) but the
accountability fiends insisted on human readable identifiers (pathnames).
The early evaluations (a decade before Linux headed for the Common
Criteria) of Unix systems got bogged down for months at a time while
the needs of objects battled with the needs of accountability.

In the end neither side is right. There are useful things that you
can do with either, but as everyone and his demented gerbil has
pointed out, no one has the True Security Solution. Not even SELinux,
which violates some pretty fundamental security principles
(see: "small enough to be analyzed") in actual deployment. TOMOYO
violates "non-circumventable", just in case anyone thinks I'm
picking on someone. Heck, even Smack isn't perfect, although I will
leave it to others to autoclave that puppy.

Those of you who say we ought to come up with a single framework
that we can use to Do The Right Thing haven't been reading the code.
We have such a framework in the LSM. Sure it's mildly hackish, but
it has only been "open" to new modules for a couple years now, and
security development tends to be slow, with no hardware and blessed
little money behind it. How many file systems went into the VFS
before it got clean enough to talk about in public?

Further, we can polish the filesystem apple until the seeds show
and still never get anywhere near where the modern security issues
reside. Right, networking. Without a security model for that we can
debate how we want our eggs cracked and get just as close to a "real"

--

[ message continues ]

.. and people are also interested in using (and expanding) the 'notify' 
layer, probably because it is obviously designed for efficiently talking 
at a user-level program about the relevant accesses. Whether that is 
because they are just crazy ("malware detection") or whether it is an 
indication that the LSM layer and current security models are just not 
convenient enough, I dunno.

And whether all that has anything to do with "Do The Rigth Thing" is 
obviously very much unclear, but the interest is clearly there.

			Linus
--

[ message continues ]

LSM layer gives enough to push the policy manager in userspace. Even
after that to a centralized server.

I worked on this, regarding networking. Next move should be to include
the LSM hooks regarding filesystem. [0]

I have concern about the way to do this, ie should we use the LSM layer
to do this, or should we put the features directly in the filesystem
stack or networking stack ?
At this point, it reminds me, ipchains (kernel 2.2) vs netfilter (kernel
2.4-2.6). At the beginning, with ipchains, filtering code was directly
in the network stack, and it wasn't the solution. So netfilter's hooks
was designed.

with LSM, we have a layer, and as sure as every one will come with his
own approach, I think we should keep code in stack (network, filesystem,
..) clean, and make the defering to userspace approach as a security
module. Then let the user/distro decided which features he want to use.

thanks,
sam

[0] http://lkml.org/lkml/2010/3/2/295
--

[ message continues ]

But that's not what the apparmor et.al. are doing.  If you want (and that's
not obviously a good thing) fine-grained access control for directory
entries, it would at least make some sense.  Prohibitively pricy, probably,
but that's a separate story.  But they are *NOT* protecting /foo/bar directory
entry when you want to protect /foo/bar/baz/barf; it doesn't go up towards
root.

And if you *do* protect each ancestor and try to keep granularity, you'll
end up with complexity from hell.
--

[ message continues ]

BTW, if you actually look at apparmor (I'd suggest tomoyo, but I'm not _that_
sadistic), you'll see how seriously do they take pathname-based *anything*.
LSM hooks for namespace operations (you know, mount, umount) are lousy, but
they exist.  Not used by apparmor.
--

[ message continues ]

That's a good point, btw, and shows one conceptual difference between 
content-based and pathname-based rules.

For example, if you want to log any changes to "/etc/passwd" (which is 
something pretty reasonable to do at least conceptually), what about doing 
a bind mount on top of that file?

That bind mount doesn't actually change the underlying file in any way. It 
doesn't even really _access_ it. From a content standpoint of the 
filesystem that contains the file, it's a total no-op.

But from an attack standpoint, you don't actually care, because nobody 
cares about the inode that used to be the contents of "/etc/passwd": all 
anybody _really_ cares about is "could somebody change what happens to the 
_name_ '/etc/passwd'".

But yeah, it's easy to overlook namespace changes when the obvious 
operations are read/write/unlink/rename. And I'm not at all surprised that 
people do.

			Linus
--

[ message continues ]

Doesn't have to be a binding over /etc/passwd, BTW.  /etc as a mountpoint will
serve just as well.
--

[ message continues ]

I agree. But I think more people are aware of a regular directory mount 
than about the ability to just mount a single file. So from a sneakyness 
standpoint, I like the "oh, btw, I just took over just the one file I care 
about" rather than trying to hide the whole directory.

Doesn't matter conceptually, though.

		Linus
--

[ message continues ]

Unfortunately, in the meantime tomoyo was merged, which is basically
apparmor done wrong.

So I guess I owe an apology to apparmor people :-(.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]