linux-kernel - Re: [PATCH] Add in_execve flag into task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1231267532.9746.116.camel@localhost.localdomain>
Date:	Tue, 06 Jan 2009 13:45:32 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Shaya Potter <spotter@...columbia.edu>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add in_execve flag into task_struct.

On Tue, 2009-01-06 at 12:09 -0500, Shaya Potter wrote:
> Serge E. Hallyn wrote:
> > Quoting Tetsuo Handa (penguin-kernel@...ove.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.

As I understand it, they want to apply the exec check against the
caller's credential as usual but not apply a read check against the
caller's credential.  This is just like the existing DAC checking (read
access to a program is not required to execute it under DAC, and you can
likely find examples of such programs in a /usr/bin near you - Xorg and
sudo are examples on a recent Fedora).  The reason it doesn't work for
them at present is that they are applying their check from the
dentry_open hook (in order to have the vfsmount available) rather than
from the inode_permission hook.

Note that they would have the same issue if they implemented
file_permission or mmap hooks that revalidate read permission (as in
SELinux).

Note btw that in the DAC case the dumpable flag gets cleared if the
caller lacks read access to the program, so TOMOYO should do likewise if
they are going to support this "execute-without-read" mode.

-- 
Stephen Smalley
National Security Agency

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