From: Shaya Potter <spotter@cs.columbia.edu>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Add in_execve flag into task_struct.
Date: Tue, 06 Jan 2009 12:09:13 -0500 [thread overview]
Message-ID: <49639039.4060708@cs.columbia.edu> (raw)
In-Reply-To: <20090106155829.GA9773@us.ibm.com>
Serge E. Hallyn wrote:
> Quoting Tetsuo Handa (penguin-kernel@i-love.sakura.ne.jp):
>> Serge,
>>
>> James is now reviewing TOMOYO Linux patch and he is caring about
>> your comment below.
>>
>> Serge E. Hallyn wrote:
>>> I don't like the 'in_exec' bit in the task_struct, but adding LSM hooks
>>> to let just TOMOYO mark whether you're in exec seems even uglier.
>> Let me (once again) ask your comment on 'in_exec' approach
>> originally suggested by David Howells ( http://lkml.org/lkml/2008/10/2/127 ).
>
> I still don't like it. Now I gather the reason for this is that you
> want to allow a less trusted domain to execute a file (in a new domain)
> without giving it the right to read it? I'd be interested in hearing
> whether others think that's a worthy goal.
I assume this has been asked and answered by whats the advantage of this
in_exec flag over a single function that set the security domain, oncee
at the beginning of exec to set the new domain (B) and once in the
fail/exit path to reset it back (to A) in case of failure.
the only difference I can see is that you want what is basically a 3rd
security domain of "execing B".
The question would then be, why is "execing B" different than B itself?
otherwise, the same changes you do to set/unset the in_exec flag could
be used to set and reset the security domains.
it just seems weird to say that we are technically in security domain A,
but are going to treat the process as if its in security domain B when
you can just as easily put it in security domain B and put it back in
security domain A if the operation fails.
but again, I could very well be missing something.
next prev parent reply other threads:[~2009-01-06 17:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-06 5:14 Tetsuo Handa
2009-01-06 15:58 ` Serge E. Hallyn
2009-01-06 17:09 ` Shaya Potter [this message]
2009-01-06 18:45 ` Stephen Smalley
2009-01-07 6:34 ` Tetsuo Handa
2009-01-07 19:06 ` Serge E. Hallyn
2009-01-08 6:17 ` Tetsuo Handa
2009-02-05 13:40 ` David Howells
2009-02-12 4:08 ` James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49639039.4060708@cs.columbia.edu \
--to=spotter@cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=serue@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®