On Thu, 24 May 2007, Andreas Gruenbacher wrote:
> > Would you mind providing some concrete examples of how such a model would
> > be useful?
>
> The model is explained, with examples, in the technical documentation at http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/.
I'm asking specifically about a model where you'd want to provide
differing access to the same objects based on the pathname used for
access to the objects, per:
"If files are mounted at multiple locations, then the policy may allow
access to some locations but not to others. That's not a hole."
I don't see specific examples of this kind of policy in that document,
and the document seems to be saying quite the opposite -- that the AA
policy is only valid in conjunction with further constraints on how the
objects may be accessed:
Section 3.2:
"Pathnames are meaningful only within a namespace. Each namespace has a
root where all the files, directories, and mount points are hanging off
from.
The privilege of creating new namespaces is bound to the CAP_ SYS_ ADMIN
capability, which grants a multitude of other things that would allow a
process to break out of AppArmor confinement, so confined processes are
not supposed to have this privilege, and processes with this capability
need to be considered trusted. "
I can restate my question and ask why you'd want a security policy like:
Subject 'sysadmin' has:
read access to /etc/shadow
read/write access to /views/sysadmin/etc/shadow
where the objects referenced by the paths are identical and visible to the
subject along both paths, in keeping with your description of "policy may
allow access to some locations but not to others" ?
- James
--
James Morris
<[email protected]>
On Thursday 24 May 2007 15:19, James Morris wrote:
> On Thu, 24 May 2007, Andreas Gruenbacher wrote:
> > > Would you mind providing some concrete examples of how such a model
> > > would be useful?
> >
> > The model is explained, with examples, in the technical documentation at
> > http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/.
>
> I'm asking specifically about a model where you'd want to provide
> differing access to the same objects based on the pathname used for
> access to the objects, per:
>
> "If files are mounted at multiple locations, then the policy may allow
> access to some locations but not to others. That's not a hole."
>
> I don't see specific examples of this kind of policy in that document,
I guess I see what you are getting at. If a user has read/write access
to /views/sysadmin/etc/shadow and if that is an alias for /etc/shadow, then
of course it doesn't help to give the user only read access to /etc/shadow to
protect that file. So you can shoot yourself in the foot with mounts, and
also with hardlinks. That's why confined processes are not allowed to mount
stuff, and why hardlinks requires the appropriate profile permissions.
AppArmor depends on the namespace so it cares about namespace manipulations,
just like SELinux depends on labels so labels matter there.
> and the document seems to be saying quite the opposite -- that the AA
> policy is only valid in conjunction with further constraints on how the
> objects may be accessed:
Read it like this: we don't have a good idea how to support multiple
namespaces so far. Currently, we interpret all pathnames relative to the
namespace a process is in. Confined processes don't have the privilege to
create or manipulate namespaces, which makes this safe. We may find a better
future solution.
> I can restate my question and ask why you'd want a security policy like:
>
> Subject 'sysadmin' has:
> read access to /etc/shadow
> read/write access to /views/sysadmin/etc/shadow
>
> where the objects referenced by the paths are identical and visible to the
> subject along both paths, in keeping with your description of "policy may
> allow access to some locations but not to others" ?
I'm not aware of situations where giving different permissions to different
paths to the same file would actually be useful. The security model doesn't
prevent it though, and it's not a security hole.
Andreas
On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote:
> Read it like this: we don't have a good idea how to support multiple
> namespaces so far. Currently, we interpret all pathnames relative to the
> namespace a process is in. Confined processes don't have the privilege to
> create or manipulate namespaces, which makes this safe. We may find a better
> future solution.
You also don't have a solution for multiple chroot jails, since they
often have the same fs mounted in many places on given box *and* since
the pathnames from the confined processes' POVs have fsck-all to do
with each other.
It's really not kinder than multiple namespaces as far as your approach
is concerned.
--- Andreas Gruenbacher <[email protected]> wrote:
> > where the objects referenced by the paths are identical and visible to the
> > subject along both paths, in keeping with your description of "policy may
> > allow access to some locations but not to others" ?
>
> I'm not aware of situations where giving different permissions to different
> paths to the same file would actually be useful. The security model doesn't
> prevent it though, and it's not a security hole.
On Fedora zcat, gzip and gunzip are all links to the same file.
I can imagine (although it is a bit of a stretch) allowing a set
of users access to gunzip but not gzip (or the other way around).
There are probably more sophisticated programs that have different
behavior based on the name they're invoked by that would provide
a more compelling arguement, assuming of course that you buy into
the behavior-based-on-name scheme. What I think I'm suggesting is
that AppArmor might be useful in addressing the fact that a file
with multiple hard links is necessarily constrained to have the
same access control on each of those names. That assumes one
believes that such behavior is flawwed, and I'm not going to try
to argue that. The question was about an example, and there is one.
Casey Schaufler
[email protected]
On Thursday 24 May 2007 20:40, Al Viro wrote:
> On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote:
>
> > Read it like this: we don't have a good idea how to support multiple
> > namespaces so far. Currently, we interpret all pathnames relative to the
> > namespace a process is in. Confined processes don't have the privilege to
> > create or manipulate namespaces, which makes this safe. We may find a
> > better future solution.
>
> You also don't have a solution for multiple chroot jails, since they
> often have the same fs mounted in many places on given box *and* since
> the pathnames from the confined processes' POVs have fsck-all to do
> with each other.
>
> It's really not kinder than multiple namespaces as far as your approach
> is concerned.
Well, the pathnames we check against are namespace relative, so no matter what
pathnames the chrooted processes think they are looking at, we always know
the actual pathnames up to ``outside the chroot''. Having the same filesystem
mounted in multiple chroots or in multiple locations in the same chroot
doesn't matter.
The main problem I see when it comes to defining per-namespace policy is that
namespaces are inherently anonymous, and there is no obvious way of
associating different sets of profiles with different namespaces.
Implementing something to also handle multiple namespaces doesn't seem
hard -- after all, it's not such a difficult concept -- but I don't have a
good enough idea what would work best.
Thanks,
Andreas
On Thursday 24 May 2007 20:58, Casey Schaufler wrote:
> On Fedora zcat, gzip and gunzip are all links to the same file.
> I can imagine (although it is a bit of a stretch) allowing a set
> of users access to gunzip but not gzip (or the other way around).
> There are probably more sophisticated programs that have different
> behavior based on the name they're invoked by that would provide
> a more compelling arguement, assuming of course that you buy into
> the behavior-based-on-name scheme. What I think I'm suggesting is
> that AppArmor might be useful in addressing the fact that a file
> with multiple hard links is necessarily constrained to have the
> same access control on each of those names. That assumes one
> believes that such behavior is flawwed, and I'm not going to try
> to argue that. The question was about an example, and there is one.
Different policy for different names of the same binary makes more obvious
sense with chroot environments. That's slightly different from having
different permissions for the same file within a single profile though.
Thanks,
Andreas
Casey Schaufler <[email protected]> writes:
> On Fedora zcat, gzip and gunzip are all links to the same file.
> I can imagine (although it is a bit of a stretch) allowing a set
> of users access to gunzip but not gzip (or the other way around).
> There are probably more sophisticated programs that have different
> behavior based on the name they're invoked by that would provide
> a more compelling arguement, assuming of course that you buy into
> the behavior-based-on-name scheme. What I think I'm suggesting is
> that AppArmor might be useful in addressing the fact that a file
> with multiple hard links is necessarily constrained to have the
> same access control on each of those names. That assumes one
> believes that such behavior is flawwed, and I'm not going to try
> to argue that. The question was about an example, and there is one.
This doesn't work. The behavior depends on argv[0], which is not
necessarily the same as the name of the file.
--
Jeremy Maitin-Shepard
Hi,
2007/5/24, James Morris <[email protected]>:
> I can restate my question and ask why you'd want a security policy like:
>
> Subject 'sysadmin' has:
> read access to /etc/shadow
> read/write access to /views/sysadmin/etc/shadow
>
> where the objects referenced by the paths are identical and visible to the
> subject along both paths, in keeping with your description of "policy may
> allow access to some locations but not to others" ?
If I understand correctly, the original issue was whether to allow passing
vfsmount to the inode_create LSM hook or not. Which is independent from
AA or "pathname based MAC", I think.
It is proven that Linux can be used without that change,$B!!(Bhowever it is
also clear that current LSM cause the ambiguities as AA people has
explained. Clearing ambiguities is a obvious gain to Linux and will make
benefits for auditing besides "pathname based MAC".
So here's my opinion. If anybody can't explain clear reason (or needs)
to keep these ambiguities unsolved,$B!!(Bwe should consider to merge
the proposal.
Thanks.
--
Toshiharu Harada
[email protected]
--- Jeremy Maitin-Shepard <[email protected]> wrote:
> Casey Schaufler <[email protected]> writes:
>
> > On Fedora zcat, gzip and gunzip are all links to the same file.
> > I can imagine (although it is a bit of a stretch) allowing a set
> > of users access to gunzip but not gzip (or the other way around).
> > There are probably more sophisticated programs that have different
> > behavior based on the name they're invoked by that would provide
> > a more compelling arguement, assuming of course that you buy into
> > the behavior-based-on-name scheme. What I think I'm suggesting is
> > that AppArmor might be useful in addressing the fact that a file
> > with multiple hard links is necessarily constrained to have the
> > same access control on each of those names. That assumes one
> > believes that such behavior is flawwed, and I'm not going to try
> > to argue that. The question was about an example, and there is one.
>
> This doesn't work. The behavior depends on argv[0], which is not
> necessarily the same as the name of the file.
Sorry, but I don't understand your objection. If AppArmor is configured
to allow everyone access to /bin/gzip but only some people access to
/bin/gunzip and (important detail) the single binary uses argv[0]
as documented and (another important detail) there aren't other links
named gunzip to the binary (ok, that's lots of if's) you should be fine.
I suppose you could make a shell that lies to exec, but the AppArmor
code could certainly check for that in exec by enforcing the argv[0]
convention. It would be perfectly reasonable for a system that is so
dependent on pathnames to require that.
Casey Schaufler
[email protected]
Casey Schaufler <[email protected]> writes:
> --- Jeremy Maitin-Shepard <[email protected]> wrote:
>> Casey Schaufler <[email protected]> writes:
>>
>> > On Fedora zcat, gzip and gunzip are all links to the same file.
>> > I can imagine (although it is a bit of a stretch) allowing a set
>> > of users access to gunzip but not gzip (or the other way around).
>> > There are probably more sophisticated programs that have different
>> > behavior based on the name they're invoked by that would provide
>> > a more compelling arguement, assuming of course that you buy into
>> > the behavior-based-on-name scheme. What I think I'm suggesting is
>> > that AppArmor might be useful in addressing the fact that a file
>> > with multiple hard links is necessarily constrained to have the
>> > same access control on each of those names. That assumes one
>> > believes that such behavior is flawwed, and I'm not going to try
>> > to argue that. The question was about an example, and there is one.
>>
>> This doesn't work. The behavior depends on argv[0], which is not
>> necessarily the same as the name of the file.
> Sorry, but I don't understand your objection. If AppArmor is configured
> to allow everyone access to /bin/gzip but only some people access to
> /bin/gunzip and (important detail) the single binary uses argv[0]
> as documented and (another important detail) there aren't other links
> named gunzip to the binary (ok, that's lots of if's) you should be fine.
> I suppose you could make a shell that lies to exec, but the AppArmor
> code could certainly check for that in exec by enforcing the argv[0]
> convention. It would be perfectly reasonable for a system that is so
> dependent on pathnames to require that.
Well, my point was exactly that App Armor doesn't (as far as I know) do
anything to enforce the argv[0] convention, nor would it in general
prevent a confined program from making a symlink or hard link. Even
disregarding that, it seems very fragile in general to make an suid
program (there would be no point in confining the execution of a
non-suid program) perform essentially access control based on argv[0].
--
Jeremy Maitin-Shepard
Jeremy Maitin-Shepard <[email protected]> writes:
> [snip]
> Well, my point was exactly that App Armor doesn't (as far as I know) do
> anything to enforce the argv[0] convention, nor would it in general
> prevent a confined program from making a symlink or hard link. Even
> disregarding that, it seems very fragile in general to make an suid
> program (there would be no point in confining the execution of a
> non-suid program) perform essentially access control based on argv[0].
Note that by "confining the execution of a non-suid program", I mean
defining an App Armor profile that prevents the execution of a
particular non-suid program, unless of course the program file itself
contains secret information, which is irrelevant to this discussion.
--
Jeremy Maitin-Shepard
--- Jeremy Maitin-Shepard <[email protected]> wrote:
> ...
> Well, my point was exactly that App Armor doesn't (as far as I know) do
> anything to enforce the argv[0] convention,
Sounds like an opportunity for improvement then.
> nor would it in general
> prevent a confined program from making a symlink or hard link. Even
> disregarding that, it seems very fragile in general to make an suid
> program (there would be no point in confining the execution of a
> non-suid program) perform essentially access control based on argv[0].
I think that you're being generous calling it fragile, but that's
my view, and I've seen much worse. I agree that it would be a Bad Idea,
but the fact that I think it's a bad idea is not going to prevent very
many people from trying it, and for those that do try it name based
access control might seem like just the ticket to complete their
nefarious schemes. Remember that security is a subjective thing, and
using argv[0] and AppArmor together might make some people feel better.
Casey Schaufler
[email protected]
On Friday 25 May 2007 19:43, Casey Schaufler wrote:
> [...] but the AppArmor code could certainly check for that in exec by
> enforcing the argv[0] convention. It would be perfectly reasonable for a
> system that is so dependent on pathnames to require that.
Hmm ... that's a strange idea. AppArmor cannot assume anything about argv[0],
and it would be a really bad idea to change the well-established semantics of
argv[0].
There is no actual need for looking at argv[0], though: AppArmor decides based
on the actual pathname of the executable...
Thanks,
Andreas
--- Andreas Gruenbacher <[email protected]> wrote:
> On Friday 25 May 2007 19:43, Casey Schaufler wrote:
> > [...] but the AppArmor code could certainly check for that in exec by
> > enforcing the argv[0] convention. It would be perfectly reasonable for a
> > system that is so dependent on pathnames to require that.
>
> Hmm ... that's a strange idea.
Yeah, I get that a lot.
> AppArmor cannot assume anything about argv[0],
>
> and it would be a really bad idea to change the well-established semantics of
>
> argv[0].
>
> There is no actual need for looking at argv[0], though: AppArmor decides
> based
> on the actual pathname of the executable...
Right. My point was that if you wanted to use the gzip/gunzip
example of a file with two names being treated differently based
on the name accessed as an argument for AppArmor you could. If
you don't want to, that's ok too. Jeremy raised a reasonable objection,
and AppArmor could address it if y'all chose to do so. I seriously
doubt that enforcing the argv[0] convention would break much, and I
also expect that if it did there's a Consultant's Retirement to be
made fixing the security hole it points out.
Casey Schaufler
[email protected]
Hello.
Casey Schaufler wrote:
> Sorry, but I don't understand your objection. If AppArmor is configured
> to allow everyone access to /bin/gzip but only some people access to
> /bin/gunzip and (important detail) the single binary uses argv[0]
> as documented and (another important detail) there aren't other links
> named gunzip to the binary (ok, that's lots of if's) you should be fine.
The argv[0] defines the default behavior of hard linked or symbolic linked programs,
but the behavior can be overridden using commandline options.
If you want to allow access to /bin/gzip but deny access to /bin/gunzip ,
you also need to deny access to "/bin/gzip -d" "/bin/gzip --decompress" "/bin/gzip --uncompress".
It is impossible to do so because options to override the default behavior
depends on program's design and you can't know
what programs and what options are there in the system.
Even if you know all programs and all options in the system,
it is a too tough job to find and reject options
that override the default behavior in the kernel space.
> > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > anything to enforce the argv[0] convention,
> Sounds like an opportunity for improvement then.
There are (I think) three types of program invocation.
(1) Invocation of hard linked programs.
/bin/gzip and /bin/gunzip and /bin/zcat are hard links.
There is no problem because you can know which pathname was requested
using d_namespace_path() with "struct linux_binprm"->file .
(2) Invocation of symbolic linked programs.
/sbin/pidof is a symbolic link to /sbin/killall .
There is a problem because you can't know which pathname was requested
using d_namespace_path() with "struct linux_binprm"->file
because the symbolic links were already derefernced inside open_exec().
To know which pathname was requested, you need to lookup
using "struct linux_binprm"->filename without LOOKUP_FOLLOW
and then use d_namespace_path().
Although there is a race condition that the pathname
the symbolic link "struct linux_binprm"->filename points to
may change, but it is inevitable because you can't get
dentry and vfsmount of both "without LOOKUP_FOLLOW flag" and
"with LOOKUP_FOLLOW flag" at the same time.
(3) Invocation of dynamically created programs with random names.
/usr/sbin/logrotate creates files patterned /tmp/logrotate.??????
and executes these dynamically created files.
To keep execution of these dynamically created files under control,
you need to aggregate pathnames of these files.
AppArmor can't define profile if the pathname of programs is random, can it?
Usually the argv[0] and the "struct linux_binprm"->filename are the same,
but if you want to do something with argv[0], you will need to handle the (2) case
to see whether the argv[0] and "struct linux_binprm"->filename are the same.
Thanks.
On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
> On Fedora zcat, gzip and gunzip are all links to the same file. I
> can imagine (although it is a bit of a stretch) allowing a set of
> users access to gunzip but not gzip (or the other way around).
That is a COMPLETE straw-man argument. I can override your "check"
with this absolutely trivial perl code:
exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
Pathname-based checks are pretty fundamentally insecure. If you want
to protect a "name", then you should tag the "name" with security
attributes (IE: AppArmor). On the other hand, if you actually want
to protect the _data_, then tagging the _name_ is flawed; tag the
*DATA* instead.
Cheers,
Kyle Moffett
Casey Schaufler wrote:
> --- Andreas Gruenbacher <[email protected]> wrote:
>
>> AppArmor cannot assume anything about argv[0],
>>
>> and it would be a really bad idea to change the well-established semantics of
>>
>> argv[0].
>>
>> There is no actual need for looking at argv[0], though: AppArmor decides
>> based
>> on the actual pathname of the executable...
>>
> Right. My point was that if you wanted to use the gzip/gunzip
> example of a file with two names being treated differently based
> on the name accessed as an argument for AppArmor you could.
AppArmor detects the pathname of the file exec'd at the time the parent
exec's it, and not anything inside the child involving argv[0].
As such, AA can detect whether you did exec("gzip") or exec("gunzip")
and apply the policy relevant to the program. It could apply different
policies to each of them, so whether it has access to /tmp/mumble/barf
depends on whether you called it 'gzip' or 'gunzip'. Caveat: it makes no
sense to profile either gzip or gunzip in the AppArmor model, so I won't
defend what kind of policy you would put on them.
Finally, AA doesn't care what the contents of the executable are. We
assume that it is a copy of metasploit or something, and confine it to
access only the resources that the policy says.
> If
> you don't want to, that's ok too. Jeremy raised a reasonable objection,
> and AppArmor could address it if y'all chose to do so. I seriously
> doubt that enforcing the argv[0] convention would break much, and I
> also expect that if it did there's a Consultant's Retirement to be
> made fixing the security 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 Software Engineering http://novell.com
Security: It's not linear
On Saturday 26 May 2007 07:20, Kyle Moffett wrote:
> On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
> > On Fedora zcat, gzip and gunzip are all links to the same file. I
> > can imagine (although it is a bit of a stretch) allowing a set of
> > users access to gunzip but not gzip (or the other way around).
>
> That is a COMPLETE straw-man argument. I can override your "check"
> with this absolutely trivial perl code:
>
> exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip", so
this confirms that the value of argv[0] is arbitrary. Well great, we already
knew.
> Pathname-based checks are pretty fundamentally insecure.
Please don't mix apples and pears. Some utilities change their behavior based
on argv[0], which indeed is not secure. It doesn't have to be for those
utilities' needs. This is different from pathname-based access control, which
is based on the pathname of the binary actually being executed.
AppArmor does not look at argv[0] for anything, and doing so would be insane.
So please don't jump to the wrong conclusions.
You can have application-level argv[0] checks in the binary that is hardlinked
to /bin/gzip, /bin/gunzip, /bin/zcat. At the same time, the kernel knows
which of these three versions it is executing, so from that point of view,
they could be as well be separate copies, and different policy can be defined
for each one of them. (This is ignoring the fact that for small utilities
like gzip, profile inheritance is usually more useful than defining separate
profiles.)
Thanks,
Andreas
Hello.
Andreas Gruenbacher wrote:
> > exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
> The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip", so
> this confirms that the value of argv[0] is arbitrary. Well great, we already
> knew.
> AppArmor does not look at argv[0] for anything, and doing so would be insane.
> So please don't jump to the wrong conclusions.
I agree that argv[0] checking is different from pathname-based access control
or label-based access control, but I want to say argv[0] checking is still needed.
If you don't check argv[0], an attacker can request everything like
exec { "/bin/ls" } "/sbin/busybox", "cat", "/etc/shadow";
exec { "/bin/ls" } "/sbin/busybox", "rm", "/etc/shadow";
if /bin/ls and /bin/cat and /bin/rm are hardlinks of /sbin/busybox (e.g. embedded systems).
Therefore, TOMOYO Linux checks the combination of filename and argv[0] passed to execve().
Thanks.
On Friday 25 May 2007 21:06, Casey Schaufler wrote:
> --- Jeremy Maitin-Shepard <[email protected]> wrote:
> > ...
> > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > anything to enforce the argv[0] convention,
>
> Sounds like an opportunity for improvement then.
Jeez, what argv[0] convention are you both talking about? argv[0] is not
guaranteed to have any association with the name of the executable. Feel free
to have any discussion about argv[0] you want, but *please* keep it away from
AppArmor, which really has nothing to do with it.
It would be nice if you could stop calling argv[0] checks ``name-based access
control'': from the point of view of the kernel no access control is
involved, and even application-level argv[0] based access control makes no
sense whatsoever.
Thanks,
Andreas
> As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> and apply the policy relevant to the program. It could apply different
That's not actually useful for programs which link the same binary to
multiple names because if you don't consider argv[0] as well I can run
/usr/bin/gzip passing argv[0] of "gunzip" and get one set of policies and
the other set of behaviour.
And then we have user added hardlinks of course.
On Saturday 26 May 2007 14:09, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
> >
> > The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip",
> > so this confirms that the value of argv[0] is arbitrary. Well great, we
> > already knew.
> >
> > AppArmor does not look at argv[0] for anything, and doing so would be
> > insane. So please don't jump to the wrong conclusions.
>
> I agree that argv[0] checking is different from pathname-based access
> control or label-based access control, but I want to say argv[0] checking
> is still needed.
>
> If you don't check argv[0], an attacker can request everything like
>
> exec { "/bin/ls" } "/sbin/busybox", "cat", "/etc/shadow";
> exec { "/bin/ls" } "/sbin/busybox", "rm", "/etc/shadow";
>
> if /bin/ls and /bin/cat and /bin/rm are hardlinks of /sbin/busybox (e.g.
> embedded systems).
>
> Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> passed to execve().
So you are indeed trying to control the value of argv[0]? Well, good luck with
that, but it's totally insane. You are guaranteed to break some applications.
AppArmor is not going to go down that route.
If /bin/cat and /bin/rm are binaries or hardlinks to the same busybox binary
(rather than symlinks), different profiles could be used for each of them.
The cat profile could have no more than read access anywhere, so this would
prevent it from removing files. That's an effective access control mechanism.
Conspiring with busybox in the kernel and making it do the right thing (and
just that) at the application level is not an effective security mechanism:
the kernel would still allow busybox to do anything, and there could be bugs
in the application, busybox's calling convention could change to allow more
than one command per invocation (e.g., ``cat /etc/shadow ; rm /etc/shadow''),
etc.
Andreas
On Saturday 26 May 2007 15:34, Alan Cox wrote:
> > As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> > and apply the policy relevant to the program. It could apply different
>
> That's not actually useful for programs which link the same binary to
> multiple names because if you don't consider argv[0] as well I can run
> /usr/bin/gzip passing argv[0] of "gunzip" and get one set of policies and
> the other set of behaviour.
I partially agree. Taken together with the policy of the calling process,
things suddenly start to make more sense though (even if gzip/gunzip don't
make good examples): if only allowed to execute /usr/bin/gzip, the calling
process can still get the gunzip behavior, but it will be bound by
the /usr/bin/gzip policy.
Controlling the policy is what we really care about; this limits the allowed
behavior. We cannot really control the behavior of an application anyway
(think of bugs alone), but we can set the bounds for that behavior.
> And then we have user added hardlinks of course.
Yes, allowing confined processes to change what they are allowed to execute
under a more permissive policy is not such a good idea.
Thanks,
Andreas
Hello.
Andreas Gruenbacher wrote:
> > Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> > passed to execve().
> So you are indeed trying to control the value of argv[0]? Well, good luck with
> that, but it's totally insane. You are guaranteed to break some applications.
TOMOYO Linux ristricts argv[0] using allow_argv0 syntax.
"allow_argv0 /bin/bash -bash" to allow passing "/bin/bash" to filename and "-bash" to argv[0] .
"allow_argv0 /bin/gzip gunzip" to allow passing "/bin/gzip" to filename and "gunzip" to argv[0] .
"allow_argv0 /sbin/busybox cat" to allow passing "/sbin/busybox" to filename and "cat" to argv[0] .
No need to use allow_argv0 syntax if the basename of filename and basename of argv[0] are the same
(i.e. "allow_argv0 /bin/bash bash" is not required).
TOMOYO Linux doesn't unconditionally forbid passing different values for filename and argv[0].
TOMOYO Linux allows passing different values for filename and argv[0] only if it is allowed by allow_argv0 syntax.
Could you please explain me why this approach breaks applications?
> If /bin/cat and /bin/rm are binaries or hardlinks to the same busybox binary
> (rather than symlinks), different profiles could be used for each of them.
It is true if all processes are kept under control (e.g. strict policy in SELinux).
If there is a process that is not kept under control (e.g. targeted policy in SELinux),
you can't protect the application.
For example, an administrator may wish to allow users run /bin/ls without applying profiles
because /bin/ls won't read/write the content of files. But a malicious user may pass
"/bin/ls" to filename and "rm" to argv[0] and "/etc/shadow" to argv[1].
A malicious user may pass "/bin/ls" to filename and "/usr/sbin/httpd" to argv[0],
resulting behave as /usr/sbin/httpd without applying profiles for /usr/sbin/httpd .
Thanks.
On Saturday 26 May 2007 16:44, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> > > passed to execve().
> >
> > So you are indeed trying to control the value of argv[0]? Well, good luck
> > with that, but it's totally insane. You are guaranteed to break some
> > applications.
>
> TOMOYO Linux restricts argv[0] using allow_argv0 syntax.
Alright, so it's configurable. This reduces it from being broken to being a
truly bad idea.
> For example, an administrator may wish to allow users to run /bin/ls without
> applying profiles because /bin/ls won't read/write the content of files.
No, forget that line of reasoning. As soon as you run anything unconfined that
isn't trusted, you have basically lost control. Relying on the fact
that /bin/ls won't do any harm is assuming to much. Features might exist that
allow it to be abused, new features might get added, or there may be bugs.
Just don't do it.
Andreas
On May 26, 2007, at 10:44:46, Tetsuo Handa wrote:
> Andreas Gruenbacher wrote:
>> Tetsuo Handa wrote:
>>> Therefore, TOMOYO Linux checks the combination of filename and
>>> argv[0] passed to execve().
>>
>> So you are indeed trying to control the value of argv[0]? Well,
>> good luck with that, but it's totally insane. You are guaranteed
>> to break some applications.
>
> TOMOYO Linux ristricts argv[0] using allow_argv0 syntax.
> "allow_argv0 /bin/bash -bash" to allow passing "/bin/bash" to
> filename and "-bash" to argv[0]. "allow_argv0 /bin/gzip gunzip" to
> allow passing "/bin/gzip" to filename and "gunzip" to argv[0].
> "allow_argv0 /sbin/busybox cat" to allow passing "/sbin/busybox" to
> filename and "cat" to argv[0]. No need to use allow_argv0 syntax
> if the basename of filename and basename of argv[0] are the same
> (i.e. "allow_argv0 /bin/bash bash" is not required). TOMOYO Linux
> doesn't unconditionally forbid passing different values for
> filename and argv[0]. TOMOYO Linux allows passing different values
> for filename and argv[0] only if it is allowed by allow_argv0 syntax.
>
> Could you please explain me why this approach breaks applications?
One of my servers runs 3 different instances of the "kadmind"
Kerberos daemon, one for each realm which I need to be able to modify/
change-passwords/etc. In order to differentiate and stop/restart the
appropriate daemon, I have a simple starter script which runs each
kadmind process with a unique name derived from the realm (EG:
"kadmind(EXAMPLE.COM)", "kadmind(OTHER.EXAMPLE.COM)"). Since this is
a Kerberos server I use a very strict SELinux-based policy, yet my
management tools need to be able to easily add and remove realms in a
secure fashion. It sounds like TOMOYO Linux would not be able to
handle this situation at all; I would either have to completely turn
off that security "feature" and lose most of the functionality of
TOMOYO Linux, or hard-code the list of realms into the policy file
and have to completely reload policy every time I need to add/remove
realms (big gaping security hole).
Cheers,
Kyle Moffett
On Fri, 25 May 2007, Crispin Cowan wrote:
> Finally, AA doesn't care what the contents of the executable are. We
> assume that it is a copy of metasploit or something, and confine it to
> access only the resources that the policy says.
As long as these resources are only files. There is no confinement beyond
that.
- James
--
James Morris
<[email protected]>
On Sat, 26 May 2007, Kyle Moffett wrote:
> AppArmor). On the other hand, if you actually want to protect the _data_,
> then tagging the _name_ is flawed; tag the *DATA* instead.
Bingo.
(This is how traditional Unix DAC has always functioned, and is what
SELinux does: object labeling).
- James
--
James Morris
<[email protected]>
--- Andreas Gruenbacher <[email protected]> wrote:
> On Friday 25 May 2007 21:06, Casey Schaufler wrote:
> > --- Jeremy Maitin-Shepard <[email protected]> wrote:
> > > ...
> > > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > > anything to enforce the argv[0] convention,
> >
> > Sounds like an opportunity for improvement then.
>
> Jeez, what argv[0] convention are you both talking about?
>From the exec(3) man page:
"The first argument, by convention, should point to the
file name associated with the file being executed."
since the man page calls it a convention, so do I.
> argv[0] is not guaranteed to have any association with the
> name of the executable. Feel free to have any discussion
> about argv[0] you want, but *please* keep it away from
> AppArmor, which really has nothing to do with it.
As I pointed out, if you wanted to trust the argv[0] value
(which I understand AppArmor makes no claims about) and you
wanted to use the argv[0] value to determine application
behavior (which several people claim is a Bad Idea) you could
use Name Based Access Control to provide different access
to the common binary. As I pointed out before, that's a lot
of "if's".
> It would be nice if you could stop calling argv[0] checks ``name-based access
>
> control'': from the point of view of the kernel no access control is
> involved, and even application-level argv[0] based access control makes no
> sense whatsoever.
Fair enough, I don't believe that an argv[0] check ought to
be used as a security mechanism. I am not convinced that everyone
would agree with us.
Casey Schaufler
[email protected]
2007/5/27, James Morris <[email protected]>:
> On Sat, 26 May 2007, Kyle Moffett wrote:
> > AppArmor). On the other hand, if you actually want to protect the _data_,
> > then tagging the _name_ is flawed; tag the *DATA* instead.
>
> Bingo.
>
> (This is how traditional Unix DAC has always functioned, and is what
> SELinux does: object labeling).
Object labeling (or labeled security) looks simple and straight forward way,
but it's not.
(1) Object labeling has a assumption that labels are always properly
defined and maintained. This can not be easily achieved.
(2) Also, assigning a label is something like inventing and assigning
a *new* name (label name) to objects which can cause flaws.
I'm not saying labeled security or SELinux is wrong. I just wanted to
remind that the important part is the "process" not the "result". :-)
--
Toshiharu Harada
[email protected]
On Sat, 26 May 2007 15:58:50 PDT, Casey Schaufler said:
> Fair enough, I don't believe that an argv[0] check ought to
> be used as a security mechanism. I am not convinced that everyone
> would agree with us.
Having seen my share of argv[0]-related security bugs in my years, I have to
agree that it's a security crock. As to why some might not agree, you already
put your finger on it earlier:
On Fri, 25 May 2007 12:06:19 PDT, Casey Schaufler said:
> nefarious schemes. Remember that security is a subjective thing, and
> using argv[0] and AppArmor together might make some people feel better.
Some people would rather just feel better...
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
> 2007/5/27, James Morris <[email protected]>:
>> On Sat, 26 May 2007, Kyle Moffett wrote:
>>> AppArmor). On the other hand, if you actually want to protect
>>> the _data_, then tagging the _name_ is flawed; tag the *DATA*
>>> instead.
>>
>> Bingo.
>>
>> (This is how traditional Unix DAC has always functioned, and is
>> what SELinux does: object labeling).
>
> Object labeling (or labeled security) looks simple and straight
> forward way, but it's not.
>
> (1) Object labeling has a assumption that labels are always
> properly defined and maintained. This can not be easily achieved.
That's a circular argument, and a fairly trivial one at that. If you
can't properly manage your labels, then how do you expect any
security at all? If you can't manage your "labels", then pathname-
based security won't work either. This is analogous to saying
"Pathname-based security has an assumption that path-permissions are
always properly defined and maintained", which is equally obvious.
If you can't achieve the first with reasonable security, then you
probably can't achieve the second either. Also, if you can't manage
correct object labeling then I'm very interested in how you are
maintaining secure Linux systems without standard DAC.
> (2) Also, assigning a label is something like inventing and
> assigning a *new* name (label name) to objects which can cause flaws.
I don't understand how assigning new attributes to objects "can cause
flaws", nor what flaws those might be; could you elaborate further?
In particular, I don't see how this is really all that more
complicated than defining additional access control in
apache .htaccess files. The principle is the same: by stacking
multiple independent security-verification mechanisms (Classical UNIX
DAC and Apache permissions) you can increase security, albeit at an
increased management cost. You might also note that ".htaccess"
files are yet another form of successful "label-based" security; the
security context for a directory depends on the .htaccess "label"
file found within. The *exact* same principles apply to SELinux: you
add additional attributes backed by a simple and powerful state-
machine. The cross-checks are lower-level than those from .htaccess
files, but the principles are the same.
Cheers,
Kyle Moffett
On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said:
> On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
> > (1) Object labeling has a assumption that labels are always
> > properly defined and maintained. This can not be easily achieved.
>
> That's a circular argument, and a fairly trivial one at that. If you
> can't properly manage your labels, then how do you expect any
> security at all?
Unfortunately, it's not at all as simple as all that. Toshiharu is quite
correct that it isn't always easy to actually implement. Consider how
many ad-croc usages of 'restorecon' are needed to get a Fedora SELinux box
through rc.sysinit:
% grep restorecon /etc/rc.sysinit
if [ -n "$SELINUX_STATE" -a -x /sbin/restorecon ] && LC_ALL=C fgrep -q " /dev " /proc/mounts ; then
/sbin/restorecon -R /dev 2>/dev/null
REBOOTFLAG=`restorecon -v /sbin/init`
[ -n "$SELINUX_STATE" ] && restorecon /dev/pts >/dev/null 2>&1
[ -n "$SELINUX_STATE" ] && restorecon /dev/mapper /dev/mapper/control >/dev/null 2>&1
[ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path"
[ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path"
[ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path"
restorecon /etc/mtab /etc/ld.so.cache /etc/blkid/blkid.tab /etc/resolv.conf >/dev/null 2>&1
[ -n "$SELINUX_STATE" ] && restorecon /tmp
[ -n "$SELINUX_STATE" ] && restorecon /tmp/.ICE-unix >/dev/null 2>&1
And that's just getting the system up to single-user. Things like sendmail
and sshd require more restorecon handholding in their rc.init files.
Or just look at the creeping horror that is 'restorecond' (in particular,
consider that the default restorcond.conf contains the strings '~/public_html'
and '~/.mozilla/plugins/libflashplayer.so'. Yee. Frikkin. Hah. ;)
On May 26, 2007, at 22:37:02, [email protected] wrote:
> On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said:
>> On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
>
>>> (1) Object labeling has a assumption that labels are always
>>> properly defined and maintained. This can not be easily achieved.
>>
>> That's a circular argument, and a fairly trivial one at that. If you
>> can't properly manage your labels, then how do you expect any
>> security at all?
>
> Unfortunately, it's not at all as simple as all that. Toshiharu is
> quite correct that it isn't always easy to actually implement.
> Consider how many ad-croc usages of 'restorecon' are needed to get
> a Fedora SELinux box through rc.sysinit:
While I don't think restorecon is really necessary to properly boot
SELinux-enabled (I've got a Debian box with some heavily customized
policy which does so just fine), I am of the opinion that adding a
"name" parameter to the file/directory create actions would be
useful. For example, with such support you could actually specify a
type-transition rule conditional on a specific name or substring:
named_type_transition sshd_t tmp_t:sock_file prefix "ssh-" ssh_sock_t;
Useful options for matching would be "prefix", "suffix", "substr
(start,len)". "regex" would be nice but is sorta computationally
intensive and would be likely to cause more problems than it solves.
> /sbin/restorecon -R /dev 2>/dev/null
> [ -n "$SELINUX_STATE" ] && restorecon /dev/mapper /dev/mapper/
> control >/dev/null 2>&1
These can go away if you modify your policy and pass "-o
fscontext=system_u:object_r:dev_t" to the mount command for the /dev
tmpfs, changing both the filesystem and the default directory labels
from the default "system_u:object_r:tmpfs_t". This will work as long
as your policy files contain appropriate transitions from the dev_t
type.
> REBOOTFLAG=`restorecon -v /sbin/init`
> restorecon /etc/mtab /etc/ld.so.cache /etc/blkid/blkid.tab /etc/
> resolv.conf >/dev/null 2>&1
> [ -n "$SELINUX_STATE" ] && restorecon /tmp
> [ -n "$SELINUX_STATE" ] && restorecon /tmp/.ICE-unix >/dev/null 2>&1
I believe these are to handle rebooting from non-SELinux mode. There
are two solutions to this kind of problem:
(1) Failing the boot if the labels are wrong
(2) Fixing the labels (and rebooting if necessary)
It would appear that FC does the latter, although for certain high-
security systems (such as firewalls handling classified/confidential
data), the first option is the only acceptable one.
> [ -n "$SELINUX_STATE" ] && restorecon /dev/pts >/dev/null 2>&1
I think this can be handled with some combination of appropriate
SELinux policy and mount options. At least, I don't need this in the
boot scripts on my heavily customized Debian SELinux box.
> [ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path"
I don't know what the point of this generic line is; but I certainly
don't have anything of the sort on my test system, and it appears to
work just fine.
> And that's just getting the system up to single-user. Things like
> sendmail and sshd require more restorecon handholding in their
> rc.init files.
>
> Or just look at the creeping horror that is 'restorecond' (in
> particular, consider that the default restorcond.conf contains the
> strings '~/public_html' and '~/.mozilla/plugins/
> libflashplayer.so'. Yee. Frikkin. Hah. ;)
Part of the reason that Fedora has a large quantity of that
restorecon and restorecond crap is that there is a certain amount of
broken binary software needing executable stack/heap (such as
flashplayer), programs without comprehensive or complete policies, or
programs which by definition need extra support for SELinux.
For example, to really complete the SELinux model you need editors
and tools which understand security labels the same way they
understand UNIX permissions. With a bit of vim scripting I can
probably make it run external commands to read file labels before it
reads the file itself and modify /proc/self/attr/fscreate before
writing out the file, similar to the way it would keep track of the
standard DAC permissions on files it modifies.
There's also the fact that corporate products have fixed release
schedules so remaining bugs in each release tend to get papered over
instead of fixed properly (such as the restorecon in FC init-
scripts). I haven't seen many problems with the SELinux model which
aren't associated with working around buggy software or missing
features.
Cheers,
Kyle Moffett
2007/5/27, Kyle Moffett <[email protected]>:
> On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
> > 2007/5/27, James Morris <[email protected]>:
> >> On Sat, 26 May 2007, Kyle Moffett wrote:
> >>> AppArmor). On the other hand, if you actually want to protect
> >>> the _data_, then tagging the _name_ is flawed; tag the *DATA*
> >>> instead.
> >>
> >> Bingo.
> >>
> >> (This is how traditional Unix DAC has always functioned, and is
> >> what SELinux does: object labeling).
> >
> > Object labeling (or labeled security) looks simple and straight
> > forward way, but it's not.
> >
> > (1) Object labeling has a assumption that labels are always
> > properly defined and maintained. This can not be easily achieved.
>
> That's a circular argument, and a fairly trivial one at that.
Sorry Kyle, I don't think it's a trivial one. The opposite.
> If you can't properly manage your labels, then how do you expect any
> security at all?
Please read my message again. I didn't say, "This can never be achieved".
I said, "This can not be easily achieved".
> If you can't manage your "labels", then pathname-
> based security won't work either. This is analogous to saying
> "Pathname-based security has an assumption that path-permissions are
> always properly defined and maintained", which is equally obvious.
Yes,! You got the point.
Both label-based and pathname-based apporaches have the advantaes and
difficluties.
In that sense they are equal. That's what I wanted to say.
Both approaches can be improved and even can be used combined to
overcome the difficulties. Let's not fight against and think together,
then we can make Linux better.
> If you can't achieve the first with reasonable security, then you
> probably can't achieve the second either. Also, if you can't manage
> correct object labeling then I'm very interested in how you are
> maintaining secure Linux systems without standard DAC.
I'm very interested in how you can know that you have the
correct object labeling (this is my point). Could you tell?
I assume your best efforts end up with
- have a proper fc definitions and guard them (this can be done)
- executes relabeling as needed (best efforts)
- hope everything work fine
> > (2) Also, assigning a label is something like inventing and
> > assigning a *new* name (label name) to objects which can cause flaws.
>
> I don't understand how assigning new attributes to objects "can cause
> flaws", nor what flaws those might be; could you elaborate further?
> In particular, I don't see how this is really all that more
> complicated than defining additional access control in
> apache .htaccess files. The principle is the same: by stacking
> multiple independent security-verification mechanisms (Classical UNIX
> DAC and Apache permissions) you can increase security, albeit at an
> increased management cost. You might also note that ".htaccess"
> files are yet another form of successful "label-based" security; the
> security context for a directory depends on the .htaccess "label"
> file found within. The *exact* same principles apply to SELinux: you
> add additional attributes backed by a simple and powerful state-
> machine. The cross-checks are lower-level than those from .htaccess
> files, but the principles are the same.
I don't deny DAC at all. If we deny DAC, we can't live with Linux
it's the base. MAC can be used to cover the shortages of DAC and
Linux's simple user model, that's it.
>From security point of view, simplicity is always the virtue and the way to go.
Inode combined label is guaranteed to be a single at any point time.
This is the most noticeable advantage of label-based security.
But writing policy with labels are somewhat indirect way (I mean, we need
"ls -Z" or "ps -Z"). Indirect way can cause flaw so we need a lot of work
that is what I wanted to tell.
Cheers,
Toshiharu Harada
[email protected]
>> On the other hand, if you actually want to protect the _data_, then
tagging the _name_ is flawed; tag the *DATA* instead.
Would it make sense to label the data (resource) with a list of paths
(names) that can be used to access it?
Therefore the data would be protected against being accessed via
alternative arbitrary names. This may be a simple label to maintain and
(possibly to) enforce, allowing path based confinement to protect a
resource. This may allow for the benefits of pathname based confinement
while avoiding some of its problems.
Obviously this would not protect against a pathname pointing to
arbitrary data?
Just a thought.
Z. Cliffe Schreuders.
CC trimmed to remove a few poor overloaded inboxes from this tangent.
On May 27, 2007, at 04:34:10, Cliffe wrote:
> Kyle wrote:
>> On the other hand, if you actually want to protect the _data_,
>> then tagging the _name_ is flawed; tag the *DATA* instead.
>
> Would it make sense to label the data (resource) with a list of
> paths (names) that can be used to access it?
>
> Therefore the data would be protected against being accessed via
> alternative arbitrary names. This may be a simple label to maintain
> and (possibly to) enforce, allowing path based confinement to
> protect a resource. This may allow for the benefits of pathname
> based confinement while avoiding some of its problems.
The primary problem with that is that "mv somefile otherfile" must
change the labels, which means that every process that issues a rename
() syscall needs to have special handling of labels. The other
problem is that many of the features and capabilities of SELinux get
left by the wayside. On an SELinux system 90% of the programs don't
need to be modified to understand labels, since the policy can define
automatic label transitions. SELinux also allows you to have
conditional label privileges based on boolean variables, something
that cannot be done if the privileges themselves are stored in the
filesystem. Finally, such an approach does not allow you to
differentiate between programs.
Cheers,
Kyle Moffett
On May 27, 2007, at 03:25:27, Toshiharu Harada wrote:
> 2007/5/27, Kyle Moffett <[email protected]>:
>> On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
>>> 2007/5/27, James Morris <[email protected]>:
>>>> On Sat, 26 May 2007, Kyle Moffett wrote:
>>>>> AppArmor). On the other hand, if you actually want to protect
>>>>> the _data_, then tagging the _name_ is flawed; tag the *DATA*
>>>>> instead.
>>>>
>>>> Bingo.
>>>>
>>>> (This is how traditional Unix DAC has always functioned, and is
>>>> what SELinux does: object labeling).
>>>
>>> Object labeling (or labeled security) looks simple and straight
>>> forward way, but it's not.
>>>
>>> (1) Object labeling has a assumption that labels are always
>>> properly defined and maintained. This can not be easily achieved.
>>
>> That's a circular argument, and a fairly trivial one at that.
>
> Sorry Kyle, I don't think it's a trivial one. The opposite.
How is that argument not trivially circular? "Foo has an assumption
that foo-property is always properly defined and maintained." That
could be said about *anything*:
* Unix permissions have an assumption that mode bits are always
properly defined and maintained
* Apache .htaccess security has an assumtion that .htaccess files
are always properly defined and maintained.
* Functional email communication has an assumption that the email
servers are always properly defined and maintained
>> If you can't properly manage your labels, then how do you expect
>> any security at all?
>
> Please read my message again. I didn't say, "This can never be
> achieved". I said, "This can not be easily achieved".
So you said "(data labels) can not be easily achieved". My question
for you is: How do you manage secure UNIX systems without standard
UNIX permission bits? Also: If you have problems with data labels
then what makes pathname based labels "easier"? If there is
something that could be done to improve SELinux and make it more
readily configurable then it should probably be done.
>> If you can't achieve the first with reasonable security, then you
>> probably can't achieve the second either. Also, if you can't
>> manage correct object labeling then I'm very interested in how you
>> are maintaining secure Linux systems without standard DAC.
>
> I'm very interested in how you can know that you have the correct
> object labeling (this is my point). Could you tell?
I know that I have the correct object labeling because:
1) I rewrote/modified the default policy to be extremely strict on
the system where I wanted the extra security and hassle.
2) I ensured that the type transitions were in place for almost
everything that needed to be done to administer the system.
3) I wrote a file-contexts file and relabeled *once*
4) I loaded the customized policy plus policy for restorecon and
relabeled for the last time
5) I reloaded the customized policy without restorecon privileges
and without the ability to reload the policy again.
6) I never reboot the system without enforcing mode.
7) If there are unexpected errors or files have incorrect labels,
I have to get the security auditor to log in on the affected system
and relabel the problematic files manually (rare occurrence which
requires excessive amounts of paperwork).
>>> (2) Also, assigning a label is something like inventing and
>>> assigning a *new* name (label name) to objects which can cause
>>> flaws.
>>
>> I don't understand how assigning new attributes to objects "can
>> cause flaws", nor what flaws those might be; could you elaborate
>> further? In particular, I don't see how this is really all that
>> more complicated than defining additional access control in
>> apache .htaccess files. The principle is the same: by stacking
>> multiple independent security-verification mechanisms (Classical
>> UNIX DAC and Apache permissions) you can increase security, albeit
>> at an increased management cost. You might also note that
>> ".htaccess" files are yet another form of successful "label-based"
>> security; the security context for a directory depends on
>> the .htaccess "label" file found within. The *exact* same
>> principles apply to SELinux: you add additional attributes backed
>> by a simple and powerful state-machine. The cross-checks are
>> lower-level than those from .htaccess files, but the principles
>> are the same.
>
> I don't deny DAC at all. If we deny DAC, we can't live with Linux
> it's the base. MAC can be used to cover the shortages of DAC and
> Linux's simple user model, that's it.
>
> From security point of view, simplicity is always the virtue and
> the way to go. Inode combined label is guaranteed to be a single
> at any point time. This is the most noticeable advantage of label-
> based security.
I would argue that pathname-based security breaks the "simplicity is
the best virtue (of a security system)" paradigm, because it
attributes multiple potentially-conflicting labels to the same piece
of data. It also cannot protect the secrecy of specific *data* as
well as SELinux can. For example: In SELinux MLS a system could
mark customer credit-card data as the "cust_private_info" category
and it would be completely impossible for any program without the
"cust_private_info" category to read that data, and even then it
could only be written to files which also have "cust_private_info"
set. While a few privileged programs may have "mlsread" or
"mlswrite" attributes allowing them to override such restrictions,
it's a much stronger security guarantee than pathname-based security
could ever provide.
> But writing policy with labels are somewhat indirect way (I mean,
> we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we
> need a lot of work that is what I wanted to tell.
I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I
do that only when I actually think I mislabeled files. Typically the
SELinux-policy-development cycle is:
1) Modify and reload the policy
2) Relabel the affected files (either by hand or with some
automated tool like restorecon)
3) Rerun the problem program or daemon
4) Examine the errors in the audit logs. If there are no errors
and it works then you're finished.
5) Go back to step 1 and fix your policy
Cheers,
Kyle Moffett
--- Cliffe <[email protected]> wrote:
> >> On the other hand, if you actually want to protect the _data_, then
> tagging the _name_ is flawed; tag the *DATA* instead.
>
> Would it make sense to label the data (resource) with a list of paths
> (names) that can be used to access it?
Program Access Lists (PALs) were* a feature of UNICOS. PALs could
contain not only the list of programs that could use them, but what
attributes the processes required as well. Further, you could
restrict or raise privilege based on the uid, gid, MAC label, and
privilege state of the process during exec based on the PAL.
> Therefore the data would be protected against being accessed via
> alternative arbitrary names. This may be a simple label to maintain and
> (possibly to) enforce, allowing path based confinement to protect a
> resource. This may allow for the benefits of pathname based confinement
> while avoiding some of its problems.
Yep, but you still have the label based system issues, the classic
case being the text editor that uses "creat new", "unlink old",
"rename new to old". When the labeling scheme is more sopisticated
than "object gets label of subject" label management becomes a major
issue.
> Obviously this would not protect against a pathname pointing to
> arbitrary data?
Protecting special data is easy. Protecting arbitrary data is the
problem.
> Just a thought.
Not a bad one, and it would be an easy and fun LSM to create.
If I were teaching a Linux kernel programming course I would
consider it for a class project.
-----
* I have used the past tense here in spite of the many
instances of UNICOS still in operation. I don't believe
that there is any current development on UNICOS.
Casey Schaufler
[email protected]
2007/5/27, Kyle Moffett <[email protected]>:
> On May 27, 2007, at 03:25:27, Toshiharu Harada wrote:
> > 2007/5/27, Kyle Moffett <[email protected]>:
> How is that argument not trivially circular? "Foo has an assumption
> that foo-property is always properly defined and maintained." That
> could be said about *anything*:
What I wanted to mention was the difficulties or efforts to make
assumptions real. I never meant a circular argument, but if you
felt so I apologize sincerely.
> >> If you can't properly manage your labels, then how do you expect
> >> any security at all?
> >
> > Please read my message again. I didn't say, "This can never be
> > achieved". I said, "This can not be easily achieved".
>
> So you said "(data labels) can not be easily achieved". My question
> for you is: How do you manage secure UNIX systems without standard
> UNIX permission bits? Also: If you have problems with data labels
> then what makes pathname based labels "easier"? If there is
> something that could be done to improve SELinux and make it more
> readily configurable then it should probably be done.
Permission bits can be checked easily with "ls" command,
but assuring the correctness of labels are not that easy.
I'll try to explain.
The correctness of the permission bit for a given file can be judged
solely by the result of "ls" command. The correctness of the label,
on the other hand, can't be judged without understanding of whole policy
including domain transitions. (see the attached figure)
I can imagine that once one get the complete SELinux policy,
then it is able to modify and maintain it.
I don't say making a complete SELinux policy is impossible,
and actually you said you did it. But to be frank, I don't think
you are the average level user at all. ;-)
> > I'm very interested in how you can know that you have the correct
> > object labeling (this is my point). Could you tell?
>
> I know that I have the correct object labeling because:
Do you mind if I add this?
0) I understood the default policy and perfectly understand the
every behavior of my system.
this is where the difficulties exist.
> 1) I rewrote/modified the default policy to be extremely strict on
> the system where I wanted the extra security and hassle.
> 2) I ensured that the type transitions were in place for almost
> everything that needed to be done to administer the system.
> 3) I wrote a file-contexts file and relabeled *once*
> 4) I loaded the customized policy plus policy for restorecon and
> relabeled for the last time
> 5) I reloaded the customized policy without restorecon privileges
> and without the ability to reload the policy again.
> 6) I never reboot the system without enforcing mode.
> 7) If there are unexpected errors or files have incorrect labels,
> I have to get the security auditor to log in on the affected system
> and relabel the problematic files manually (rare occurrence which
> requires excessive amounts of paperwork).
Thank you for the procedures. It's quite helpful.
> > I don't deny DAC at all. If we deny DAC, we can't live with Linux
> > it's the base. MAC can be used to cover the shortages of DAC and
> > Linux's simple user model, that's it.
> >
> > From security point of view, simplicity is always the virtue and
> > the way to go. Inode combined label is guaranteed to be a single
> > at any point time. This is the most noticeable advantage of label-
> > based security.
>
> I would argue that pathname-based security breaks the "simplicity is
> the best virtue (of a security system)" paradigm, because it
> attributes multiple potentially-conflicting labels to the same piece
Every pathname-based security must provide the mechanism
to prevent a conflicting/malicious access, otherwise it's junk.
I have a question for you. With current implementation of
SELinux, only one label can be assigned. But there are cases
that one object can be used in different context, so I think
it might help if SELinux would allow objects to have
multiple labels. (I'm not talking about conflicts here)
What do you think?
> > But writing policy with labels are somewhat indirect way (I mean,
> > we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we
> > need a lot of work that is what I wanted to tell.
>
> I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I
> do that only when I actually think I mislabeled files.
I believe what you wrote, but it may not be as easy for average Linux users.
> Typically the SELinux-policy-development cycle is:
> 1) Modify and reload the policy
> 2) Relabel the affected files (either by hand or with some
> automated tool like restorecon)
> 3) Rerun the problem program or daemon
> 4) Examine the errors in the audit logs. If there are no errors
> and it works then you're finished.
> 5) Go back to step 1 and fix your policy
Cheers,
Toshiharu Harada
Hi!
> >>That's a circular argument, and a fairly trivial one
> >>at that. If you
> >>can't properly manage your labels, then how do you
> >>expect any
> >>security at all?
> >
> >Unfortunately, it's not at all as simple as all that.
> >Toshiharu is quite correct that it isn't always easy
> >to actually implement. Consider how many ad-croc
> >usages of 'restorecon' are needed to get a Fedora
> >SELinux box through rc.sysinit:
>
> While I don't think restorecon is really necessary to
> properly boot SELinux-enabled (I've got a Debian box
> with some heavily customized policy which does so just
> fine), I am of the opinion that adding a "name"
> parameter to the file/directory create actions would be
> useful. For example, with such support you could
> actually specify a type-transition rule conditional on
> a specific name or substring:
>
> named_type_transition sshd_t tmp_t:sock_file prefix
> "ssh-" ssh_sock_t;
>
> Useful options for matching would be "prefix", "suffix",
> "substr (start,len)". "regex" would be nice but is
> sorta computationally intensive and would be likely to
> cause more problems than it solves.
Could someone implement this? AFAICT that prevents SELinux from being
superset of AppArmor... Doing this should be significantly simpler
than whole AA, and hopefully it will end up less ugly, too.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On May 28, 2007, at 06:41:11, Toshiharu Harada wrote:
> 2007/5/27, Kyle Moffett <[email protected]>:
>>>> If you can't properly manage your labels, then how do you expect
>>>> any security at all?
>>> Please read my message again. I didn't say, "This can never be
>>> achieved". I said, "This can not be easily achieved".
>>
>> So you said "(data labels) can not be easily achieved". My
>> question for you is: How do you manage secure UNIX systems without
>> standard UNIX permission bits? Also: If you have problems with
>> data labels then what makes pathname based labels "easier"? If
>> there is something that could be done to improve SELinux and make
>> it more readily configurable then it should probably be done.
>
> Permission bits can be checked easily with "ls" command but
> assuring the correctness of labels are not that easy. I'll try to
> explain.
>
> The correctness of the permission bit for a given file can be
> judged solely by the result of "ls" command. The correctness of
> the label, on the other hand, can't be judged without understanding
> of whole policy including domain transitions. (see the attached
> figure) I can imagine that once one get the complete SELinux
> policy, then it is able to modify and maintain it.
That's why there are a number of efforts to make modular SELinux
policies. A good SELinux policy provides a few core system types and
labels which a policy developer needs to understand, as well as some
good macros to simplify the human-editable policy files. For
instance, in my customized policy a daemon run by an initscript which
reads a single config file in /etc needs this policy (Note that I use
"_d" as a suffix for process domains instead of the usual "_t"):
initrc_daemon(foo_exec_t, foo_d)
daemon_config(foo_d, foo_conf_t)
Add maybe 2 lines for network port access, another 2 for database
files in /var, plus maybe an "iptables" rule or two in your firewall
file.
> I don't say making a complete SELinux policy is impossible, and
> actually you said you did it. But to be frank, I don't think you
> are the average level user at all. ;-)
Average users are not supposed to be writing security policy. To be
honest, even average-level system administrators should not be
writing security policy. It's OK for such sysadmins to tweak
existing policy to give access to additional web-docs or such, but
only expert sysadmin/developers or security professionals should be
writing security policy. It's just too damn easy to get completely
wrong.
>>> I'm very interested in how you can know that you have the correct
>>> object labeling (this is my point). Could you tell?
>>
>> I know that I have the correct object labeling because:
>
> Do you mind if I add this?
>
> 0) I understood the default policy and perfectly understand the
> every behavior of my system.
>
> this is where the difficulties exist.
You don't have to understand the entire default policy; that's the
point of modular policy. You only have to understand how to _use_
the interfaces of the system policy (which are documented) and how
the particular daemon policy is supposed to work. The people
developing the core system policy need to understand the inner
workings of said policy, but they don't need to understand how the
rest of the system works. The core functionality behind this
separation is macro interfaces and attributes. By grouping types
with attributes it is possible for arbitrary daemon types to
categorize themselves under access rules defined by the base policy,
and with interfaces the daemons don't really even need to know what
those attributes are called.
>>> I don't deny DAC at all. If we deny DAC, we can't live with
>>> Linux it's the base. MAC can be used to cover the shortages of
>>> DAC and Linux's simple user model, that's it.
>>>
>>> From security point of view, simplicity is always the virtue and
>>> the way to go. Inode combined label is guaranteed to be a single
>>> at any point time. This is the most noticeable advantage of
>>> label-based security.
>>
>> I would argue that pathname-based security breaks the "simplicity
>> is the best virtue (of a security system)" paradigm, because it
>> attributes multiple potentially-conflicting labels to the same piece
>
> I have a question for you. With current implementation of SELinux,
> only one label can be assigned. But there are cases
> that one object can be used in different context, so I think it
> might help if SELinux would allow objects to have multiple labels.
> (I'm not talking about conflicts here) What do you think?
This is the whole advantage of SELinux type attributes: you can
define a type "var_foo_t" which has a specific list of attributes;
rules which accept type specifiers can also accept attribute
specifiers as well. If what you want is a label which may be
accessed in two different ways, then you declare attributes for each
access method and declare a type which has the attributes "filetype",
"access1", and "access2" (assuming access1 and access2 are the names
of the attributes you declared and used in your access rules).
>>> But writing policy with labels are somewhat indirect way (I mean,
>>> we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we
>>> need a lot of work that is what I wanted to tell.
>>
>> I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I
>> do that only when I actually think I mislabeled files.
>
> I believe what you wrote, but it may not be as easy for average
> Linux users.
As I said before, average Linux users should not be writing their own
security policy. I have yet to meet an "average Linux user" who
could reliably quote for me what the file permissions on the "/tmp"
directory should be, or what the sticky bit was. A small percentage
of average Linux system administrators don't get that right
consistently, and if you don't understand the sticky bit then you
should *definitely* not be controlling program permissions on a per-
syscall basis.
Cheers,
Kyle Moffett
On May 28, 2007, at 16:38:38, Pavel Machek wrote:
> Kyle Moffett wrote:
>> I am of the opinion that adding a "name" parameter to the file/
>> directory create actions would be useful. For example, with such
>> support you could actually specify a type-transition rule
>> conditional on a specific name or substring:
>>
>> named_type_transition sshd_t tmp_t:sock_file prefix "ssh-"
>> ssh_sock_t;
>>
>> Useful options for matching would be "prefix", "suffix", "substr
>> (start,len)". "regex" would be nice but is sorta computationally
>> intensive and would be likely to cause more problems than it solves.
>
> Could someone implement this? AFAICT that prevents SELinux from
> being superset of AppArmor... Doing this should be significantly
> simpler than whole AA, and hopefully it will end up less ugly, too.
Really it would need to extend all action-match items with new
"named_" equivalents, and most callbacks would need to be extended to
pass in an object name, if available. On the other hand, with such
support implemented then the AppArmor policy compilation tools could
be transformed into a simple SELinux policy generator. I estimate
that the number of new lines of kernel code for such a modified
SELinux would be 100x less than the kernel code in AppArmor.
Cheers,
Kyle Moffett
On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said:
> Average users are not supposed to be writing security policy. To be
> honest, even average-level system administrators should not be
> writing security policy. It's OK for such sysadmins to tweak
> existing policy to give access to additional web-docs or such, but
> only expert sysadmin/developers or security professionals should be
> writing security policy. It's just too damn easy to get completely
> wrong.
The single biggest challenge in computer security at the present time is how to
build *and deploy* servers that stay reasonably secure even when run by the
average wave-a-dead-chicken sysadmin, and desktop-class boxes that can survive
the best attempts of Joe Sixpack's "Ooh shiny" reflex, and Joe's kid's attempts
to evade the nannyware that Joe had somebody install.
(If you know how to build such things, don't bother replying. If you have
actual field experience on getting significant percents of Joe Sixpacks to
switch, I need to buy you a beer or something.. ;)
2007/5/29, Kyle Moffett <[email protected]>:
> >>> But writing policy with labels are somewhat indirect way (I mean,
> >>> we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we
> >>> need a lot of work that is what I wanted to tell.
> >>
> >> I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I
> >> do that only when I actually think I mislabeled files.
> >
> > I believe what you wrote, but it may not be as easy for average
> > Linux users.
>
> As I said before, average Linux users should not be writing their own
> security policy. I have yet to meet an "average Linux user" who
> could reliably quote for me what the file permissions on the "/tmp"
> directory should be, or what the sticky bit was. A small percentage
> of average Linux system administrators don't get that right
> consistently, and if you don't understand the sticky bit then you
> should *definitely* not be controlling program permissions on a per-
> syscall basis.
Thank you for your detailed and thoughtful explanation.
Things are much clear now for me. Although your explanation was
quite persuasive, I still have some concerns.
Linux is now being used literately everywhere. As devices, technologies and
Linux itself is evolving so quickly, I'm afraid the way you showed was right
but could never meet the every goal perfectly. So some areas, including
embedded and special distro I guess, there must be solutions and help for
average level administrators.
I think there are two ways to make secure systems. One is just
you wrote: "ask it professionals" way, the other is "making practices".
You might ask "how?" My answer to the question is pahtname-based
systems such as AppAmor and TOMOYO Linux.
They can't be compared to SELinux, but they should be considered to
supplemental tools. At least they are helpful to analyze how Linux works.
Tweeking SELinux policy is not easy but writing policies for
them is relatively easy (I'm not talking about security here).
Not everybody can be a professional administrators, but he/she can be a
professional administrator of his/her system. I believe there must be
solutions for non professional administrators. That's why we developed
TOMOYO Linux (http://tomoyo.sourceforge.jp/) and so was AppArmor
I guess. You might laugh, but we are doing this because we want to
contribute to Linux and its community. :)
Thanks,
Toshiharu Harada
[email protected] wrote:
> On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said:
>
>> Average users are not supposed to be writing security policy. To be
>> honest, even average-level system administrators should not be
>> writing security policy.
That explains so much! "SELinux: you're too dumb to use it, so just keep
your hands in your pockets." :-)
AppArmor was designed to allow your average sys admin to write a
security policy. It makes different design choices than SELinux to
achieve that goal. As a result, AppArmor is an utter failure when
compared to SELinux's goals, and SELinux in turn is an utter failure
when compared to AppArmor's goals.
Which is why we have LSM: so we don't have to have this argument here,
again.
>> It's OK for such sysadmins to tweak
>> existing policy to give access to additional web-docs or such, but
>> only expert sysadmin/developers or security professionals should be
>> writing security policy. It's just too damn easy to get completely
>> wrong.
>>
> The single biggest challenge in computer security at the present time is how to
> build *and deploy* servers that stay reasonably secure even when run by the
> average wave-a-dead-chicken sysadmin, and desktop-class boxes that can survive
> the best attempts of Joe Sixpack's "Ooh shiny" reflex, and Joe's kid's attempts
> to evade the nannyware that Joe had somebody install.
>
That is a tall order. You can mostly achieve it by not giving the user
the root password, but I'm not sure you would like the result :-)
Both SELinux and AppArmor can be configured so tightly that you are not
going to get to install 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, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
Security: It's not linear
> >> honest, even average-level system administrators should not be
> >> writing security policy.
> That explains so much! "SELinux: you're too dumb to use it, so just keep
> your hands in your pockets." :-)
Hardly. And there are helper tools
>
> AppArmor was designed to allow your average sys admin to write a
> security policy.
Which is a bit like giving a small child an Uzi 9mm and inviting them to
teach themselves to shoot.
> Both SELinux and AppArmor can be configured so tightly that you are not
> going to get to install 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.
That depends who owns the admin password. That kind of thing (coupled
with 'can install approved packages' and suitable policy) works very well
in some environments where the user doesn't get the admin password - ie
much of business.
Hi!
> >> Average users are not supposed to be writing security policy. To be
> >> honest, even average-level system administrators should not be
> >> writing security policy.
> That explains so much! "SELinux: you're too dumb to use it, so just keep
> your hands in your pockets." :-)
>
> AppArmor was designed to allow your average sys admin to write a
> security policy. It makes different design choices than SELinux to
> achieve that goal. As a result, AppArmor is an utter failure when
> compared to SELinux's goals, and SELinux in turn is an utter failure
> when compared to AppArmor's goals.
I'd not be that sure. SELinux can read AA config files, with some
performance problems and bad problems with new files.
I bet solving the 'new files' problem is not going to take 20% of AA's
size...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html