t; regardless.
>
libapparmor exists. It only had one API, and now it has 2, but just 2
versions on the same concept (change_hat and change_profile).
This is the API for change_hat http://man-wiki.net/index.php/2:change_hat
What does the corresponding API in SELinux look like?
Crispin
--
daemon's own security context? That seems entirely
> reasonable to me.
>
That semantically maps well to the AppArmor change_profile() API, so
conceptually it should work. It would be easier if you did that in user
space instead of in the kernel, I don't know if it causes a p
James Morris wrote:
> On Fri, 30 Nov 2007, Crispin Cowan wrote:
>> restored faces a lot of challenges, but I hope that some kind of
>> solution can be found, because the alternative is to effectively force
>> vendors like Sophos to do it the "dirty" way by fishi
er that Linux offers you a way to do
what you need to do than force you to do nasty things.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
-
Kyle Moffett wrote:
> On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote:
>> Andrew Morgan wrote:
>>> It feels to me as if a MAC "override capability" is, if true to its
>>> name, extra to the MAC model; any MAC model that needs an 'override'
>>&
that effect).
>
I don't get the difference. Both seem to permit the process to violate
the MAC policy. I could make up a meaning for MAC_ADMIN that is
different from MAC_OVERRIDE in the AppArmor sense, but I don't want to
:-) and worse, I suspect the distinction would be different for
ter view (a I do) then the meaning of MAC_READ vs.
MAC_WRITE, and especially MAC_RELABEL_SUBJECT, becomes murky, e.g. I
have no clue WtF "relabel subject" means to AppArmor. But I can very
easily understand what "CAP_MAC_OVERRIDE" means to AppArmor.
So I'm with Casey; I s
Peter Dolding wrote:
> On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
>> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>>> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
>>>
>>>> Pete
uld you corrupt that with separate
LSM modules per container?
What makes sense to me is to ensure that it is easy for an LSM module to
have a policy per container. This is relatively easy to do, and maps
very well to the primary use of containers for hosting virtual domains.
Crispi
e the "influence"
> of the confined process anyway.
>
It counts as a surprising result, and so is specifically disclaimed. I
can tell it is surprising, because it surprised Andi Kleen :)
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux
.
Another way to do it is what JJ posted: enhance the rule language so you
can have one rule for files that you own, and a different rule for files
owned by others. The AppArmor community (well, JJ and I :) are debating
the cost/benefit of this: is the added flexibility worth the added
comp
g else and edit it a bit, and then load it.
The big difference between the former and latter is that the former is
inflexible (it either works or it doesn't) and the latter requires
privilege.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenar
Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
>
>> I mostly don't see this as a serious limitation, because almost everyone
>> has their own workstation, and thus has root on that workstation. There
>> are 2 major exceptions:
&
Not "is it exactly what I want?" but merely
"is it non-silly, such that clearly it provides value to some users?"
* Does the code live up to the model?
I submit that the AppArmor model is valid, even if it totally failed all
of David Gilbert's questions (I think
Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
>
>> I don't get the problem: if you want your web browser to be able to
>> access where you commonly store your documents, then give it that
>> permission. The above rule says that your
Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> > * Manipulating AppArmor policy requires being both root privileged
>> and not being confined by AppArmor, thus there is explicitly no
>> capability for non-privileged users to c
Andi Kleen wrote:
> Crispin Cowan <[EMAIL PROTECTED]> writes:
>
> The document should be a good base for a merge.
>
>
>> * A confined process can operate on a file descriptor passed to it
>> by an unconfined process, even if it manipulates a file not i
re-sent due to a typo in addressing.
AppArmor Security Goal
Crispin Cowan, PhD
MercenaryLinux.com
This document is intended to specify the security goal that AppArmor is
intended to achieve, so that users can evaluate whether AppArmor will
meet their needs, and kernel developers can evaluate
esting, you can do that with any policy system. To show
"dangerous" you would have to show how a reasonable policy that should
be secure is in fact bypassable. This threat from mount point aliases,
this has often been conjectured but has never been shown.
Crispin
--
Crispin Cowan, Ph.D.
heck the security_ops of the
> secondary LSM(s) and complain if it considers there to be an incompatiblity.
>
That is what I advocate. Restore the modular feature immediately, this
static interface is lots of cost (mostly opportunity cost) and very
little benefit (mostly defense against contrived FU
ux and load TOMOYO. Oh, you can't because someone has
made modules not be loadable :( Hmmm, perhaps someone could fix that by
reverting the static interface patch ... :)
> May be we should consider stackable LSM again?
>
Exactly. Stacker was shelved, so to speak :) because of
ecially not without a clear design that addresses
clearly stated problems that lots of people are having.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity a
http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi
* Similar talk at linux.conf.au 2007
http://youtube.com/watch?v=EgrfmSm0NWs
* Similar talk at Defcon 2007
http://video.google.com/videoplay?docid=-1731833784646588861&hl=en
Crispin
--
Crispin Cowan, Ph.D.
excuse to ban
syringes and demand that everyone be born with a strong immune system.
Why is it that security flame wars always end up reasoning with absurd
analogies? :-)
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercena
Rob Meijer wrote:
> On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
>
>>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>>> modules as proposed, alternatively a maintainer for each formal model
>>> may be more appropriate. This also
should we exclude one and keep
the other? No, of course not, because in practice they are very
different.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Co
to
be useful. But IMHO that bar of "too narrow" should be very, very low.
Defenses against specific modes of attack would be a fine thing to build
up in the library of LSMs, especially if we got a decent stacking module
so that they could be composed.
Crispin
--
Crispin Cowan, Ph.
e I will strive to be
both clear and precise, achieving both is challenging. So, if someone
discovers a mis-match between the description and the code, would a
patch to the description be an acceptable resolution, if it did not
render the model silly?
Crispin
--
Crispin Cowan, Ph.D.
kernel.
Open source is great, and it is wonderful that you *can* hack the source
if you need to, but demanding that end users patch their source code
when all they want to do is load a module is really, really sad.
Please revert this patch. Its benefits are no where near its costs.
Crispin
-
ew
kind of device and device driver.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Itanium. Vista. GPLv3. Complexity at work
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
M
address really big enough
to bother fixing at all? Maybe, but I don't know. Again, I'm
strictly opposed to the loss of flexibility until the performance
issue is documented, and then I would rather see it be a
configuration option you can choose to inline your modu
a catastrophe, it is just tedious. It does not kill baby
seals, and it does not make Linux utterly useless. OTOH, I think it is
strictly negative: it takes away user choice in 2 dimensions, and adds
zero value. So apply it if you must to bake the kernel developer's lives
easier, but it
oes is make it harder for newer
modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise
users. So I don't think I am being self-serving in arguing against this
patch. I just think it is bad for Linux.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
wever, I have never considered the idea of separate LSM modules per
container. The idea doesn't really make sense to me. It is kind of like
asking for private device drivers, or even a private kernel, per name
space. If that's what you want, use virtualization like KVM, Xen, or VMware.
Cri
at's not the case.
>
And you claim you are not a security expert :-)
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Itanium. Vista. GPLv3. Complexity at work
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
, so users can
decide on an appropriate mechanism.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
-
To unsubscribe from this list: send the line "unsubscribe l
Sean wrote:
> On Wed, 27 Jun 2007 14:06:04 -0700
> Crispin Cowan <[EMAIL PROTECTED]> wrote:
>
>> I am hoping for a reconciliation where the people who don't like
>> AppArmor live with it by not using it. AppArmor is not intended to
>> replace SELinux, it
cause it's easier to use - and although it's technically
> inferior.
AppArmor's advantages come from the model, not the tools. AppArmor is
not inferior to SELinux, it is different than SELinux. Neither can
replace the other without horrid kludges.
Crispin
--
Crispin Cowan, Ph.D.
mmod, and leave
in place the ability to modprobe? Or even easier, LSMs that don't want
to be unloaded can just block rmmod, and simple LSMs that can be
unloaded safely can permit it.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Enginee
r because of your policy language,
> that's your issue to solve, not ours.
I think it is a little more fundamental than that. If you are going to
do pathname based access control at all, you need access to sufficient
information to compute the path name. Can we have a discussion
hat's kind of a technical issue, right?
>
So if the document said "confinement with respect to direct file access
and POSIX.1e capabilities" and that list got extended as AA got new
confinement features, would that address your issue?
Crispin
--
Crispin Cowan, Ph.D.
Greg KH wrote:
> On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
>
>> Then there's all the other problems, such as file systems that don't
>> support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable
>> to network attack, but that
7;t
support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable
to network attack, but that is not the threat AA is addressing. AA is
preventing an application with access to an NFS mount from accessing the
*entire* mount. There is lots of practical security value in this, and
label scheme
nied.
o default-allow system wide: unconfined processes are allowed
to do anything that classic DAC permissions allow.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor
about the best way to implement AA. Some have alleged
that AA layered on top of SELinux is the best way. I think that is
clearly wrong; AA layered on top of SELinux is possible, but would
require a bunch of enhancements to SELinux first, and the result would
be more complex than the propo
n.
* It would make AppArmor's ability to change policies on a live
system more difficult.
* The necessary extensions would not be appealing to the SELinux
community.
LSM is the common code that AA and SELinux have agreed to be mutually
useful. Forcing AA to sit on top of S
stall malware, by preventing the user from installing
software. This isn't what users want, so they invariably bypass security
and install shiny things if they own the box. SELinux and AppArmor can't
help but fail if you put them in that kind of harm's way.
Crispin
--
Crispin Cowan,
intentional, and contributes to AppArmor's ease of use, and does not
generate a hole if you consider every process exposed to (say) network
attack and confine it.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novel
he other hand, you would get the management
problems of both AppArmor and SELinux; you would have to solve both the
new file problem, and the file alias problem. Think about what you would
have to do to accommodate (say) a text editor's file save procedure of
"write new file.tmp, rename oldfile
urity hole it points out.
>
AppArmor does address it, and I hope this explains how we detect which
of multiple hard links to a file you used to access the file without
mucking about with argv[0].
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of S
patches is a self-contained access control system
for file system access, and we would like it reviewed as such. Current
AppArmor docs are quite explicit that AppArmor only mediates file access
and POSIX.1e capabilities.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~cr
non-label schemes for effective
confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS,
AS400, to name just a few. This claim seems bogus. Labels may be your
method of choice for confinement, but they are far from the only way.
Crispin
--
Crispin Cowan, Ph.D.
o achieve ease of
use. If you want information flow control, then by all means use a
label-based system.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
-
To unsubscribe from this list: send the line "unsubscrib
process gets when they open the well-known
"/etc/resolv.conf". Which is why it is useful to guard which processes
can read or write to /etc/resolv.conf; the name is what makes its
content special, not the other way around.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.
compatible with each other
anyway, I don't really care :)
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com
Hacking is exploiting the gap between "intent" and "implementation"
then you do have
more of an optimization issue. However, I then submit that the correct
optimization is to choke down the check so that it is only performed on
root exec's that represent logins rather than all execs, instead of
trying to make the check go faster.
Crispin
--
Crispin Cowan, Ph.D.
Lorenzo Hernández García-Hierro wrote:
El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió:
Lorenzo Hernández García-Hierro wrote:
You are confused. It is Secure Computing Corporation that holds patents
that threaten SELinux
http://www.securecomputing.com/pdf
reaten SELinux
http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf
Immunix has never threatened any open source project with patent
infringement.
Please get your facts straight before accusing someone of a serious act
like that.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, I
r by
sending e-mail to [EMAIL PROTECTED] with a subject
of "subscribe".
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
-
To unsubscribe from this list: send the line "unsubscri
59 matches
Mail list logo
