Christoph Hellwig writes:
On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote:
We limit the maximum length of any string data (such as
domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN
(which is 4000) bytes to fit within a single page.
Userland programs can obtain the amount of
Hello.
I just now made demo movies how TOMOYO Linux looks like.
http://tomoyo.sourceforge.jp/data/CentOS5-install.avi is
a movie that demonstrates how to install TOMOYO Linux 1.4.1 on CentOS 5.
http://tomoyo.sourceforge.jp/data/CentOS5-learning.avi is
a movie that demonstrates how the TOMOYO Lin
Hi!
> I also don't care about the details of how it gets
> implemented, but when the AA people have a working
> implementation, and the SELinux people are strongly
> opposed to the concept, I don't see any advantage in
Actually, SELinux people 'liked' the concept -- they are willing to
extend
Hi!
> >>We limit the maximum length of any string data (such as
> >>domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN
> >>(which is 4000) bytes to fit within a single page.
> >>
> >>Userland programs can obtain the amount of RAM
> >>currently
> >>used by TOMOYO from /proc interface.
> >
> >Sam
On Sun, Jun 10, 2007 at 10:09:18AM -0700, Crispin Cowan wrote:
> Andreas Gruenbacher wrote:
> > On Saturday 09 June 2007 02:17, Greg KH wrote:
> >
> >> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
> >>
> >>> AppArmor is meant to be relatively easy to understand, mana
On Thu, Jun 14, 2007 at 05:18:43PM -0700, [EMAIL PROTECTED] wrote:
> On Thu, 14 Jun 2007, Jack Stone wrote:
>
> > [EMAIL PROTECTED] wrote:
> >> On Sun, 10 Jun 2007, Pavel Machek wrote:
> >>> But you have that regex in _user_ space, in a place where policy
> >>> is loaded into kernel.
> >>
> >> th
On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> --- Greg KH <[EMAIL PROTECTED]> wrote:
>
>
> > A daemon using inotify can "instantly"[1] detect this and label the file
> > properly if it shows up.
>
> In our 1995 B1 evaluation of Trusted Irix we were told in no
> uncertain terms that
--- Greg KH <[EMAIL PROTECTED]> wrote:
> A daemon using inotify can "instantly"[1] detect this and label the file
> properly if it shows up.
In our 1995 B1 evaluation of Trusted Irix we were told in no
uncertain terms that such a solution was not acceptable under
the TCSEC requirements. Detecti
Hi!
And before you scream "races", take a look. It does not actually add
them:
> > > I agree that the in-kernel implementation could use different
> > > abstractions
> > > than user-space, provided that the underlying implementation details can
> > > be
> > > hidden well enough. The key phras
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> > --- Greg KH <[EMAIL PROTECTED]> wrote:
> >
> >
> > > A daemon using inotify can "instantly"[1] detect this and label the file
> > > properly if it shows up.
> >
> > In our 1995 B1 eva
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Hi!
>
> And before you scream "races", take a look. It does not actually add
> them:
Hey, I never screamed that at all, in fact, I completly agree with you
:)
> > > > I agree that the in-kernel implementation could use different
>
On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
>
> Yup, I see that once you accept the notion that it is OK for a
> file to be misslabeled for a bit and that having a fixxerupperd
> is sufficient it all falls out.
>
> My point is that there is a segment of the security community
On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> >
> > Yup, I see that once you accept the notion that it is OK for a
> > file to be misslabeled for a bit and that having a fixxerupperd
> > is sufficient it all falls out.
> >
>
On Fri, 15 Jun 2007, Greg KH wrote:
> > Or just create the files with restrictive labels by default. That way
> > you "fail closed".
>
> From my limited knowledge of SELinux, this is the default today so this
> would happen by default. Anyone with more SELinux experience want to
> verify or fix
On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > >
> > > Yup, I see that once you accept the notion that it is OK for a
> > > file to be misslabeled for a bit
On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote:
> On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> > On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > > >
> > > > Yup, I see that once you accept the notio
--- Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> >
> > Yup, I see that once you accept the notion that it is OK for a
> > file to be misslabeled for a bit and that having a fixxerupperd
> > is sufficient it all falls out.
> >
> > My poi
Greg KH wrote:
> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
>
* Renamed Directory trees: The above problem is compounded with
directory trees. Changing the name at the top of a large, bushy
tree can require instant relabeling of millions of files
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Yes, you may get some -EPERM during the tree move, but AA has that
> problem already, see that "when madly moving trees we sometimes
> construct path file never ever had".
Pavel, please focus on the current AppArmor implementation. Yo
Hi!
> > Yes, you may get some -EPERM during the tree move, but AA has that
> > problem already, see that "when madly moving trees we sometimes
> > construct path file never ever had".
>
> Pavel, please focus on the current AppArmor implementation. You're
> remembering a flaw with a previous versi
On Fri, Jun 15, 2007 at 05:42:08PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > > Or just create the files with restrictive labels by default. That way
> > > you "fail closed".
> >
> > From my limited knowledge of SELinux, this is the default today so this
> > would happ
On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> Greg KH wrote:
> > On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> >
> * Renamed Directory trees: The above problem is compounded with
> directory trees. Changing the name at the top of a large,
On Fri, 15 Jun 2007, Greg KH wrote:
On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
Greg KH wrote:
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
Only case where attacker _can't_ be keeping file descriptors is newly
created files in recently moved tree. But as yo
Hi!
> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem alread
On Sat, Jun 16, 2007 at 01:39:14AM +0200, Pavel Machek wrote:
> > Pavel, please focus on the current AppArmor implementation. You're
> > remembering a flaw with a previous version of AppArmor. The pathnames
> > constructed with the current version of AppArmor are consistent and
> > correct.
>
> Ok
On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > We have built a label-based AA prototype. It fails because there is no
> > reasonable way to address the tree renaming problem.
>
> How does inotify not work here? You are notified that the tree is
> moved, your daemon goes through and
Hi!
> >>Under the restorecon proposal, the web site would be horribly broken
> >>until restorecon finishes, as various random pages are or are not
> >>accessible to Apache.
> >
> >Usually you don't do that by doing a 'mv' otherwise you are almost
> >guaranteed stale and mixed up content for some p
On Fri, Jun 15, 2007 at 05:18:10PM -0700, Seth Arnold wrote:
> On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > > We have built a label-based AA prototype. It fails because there is no
> > > reasonable way to address the tree renaming problem.
> >
> > How does inotify not work here? Y
On Fri, Jun 15, 2007 at 05:01:25PM -0700, [EMAIL PROTECTED] wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> >> Greg KH wrote:
> >>> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Only case where attacker _ca
Crispin Cowan wrote:
> In a smaller scale example, I want to share some files with a friend. I
> can't be bothered to set up a proper access control system, so I just mv
> the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> going away in 10 minutes" and then move it out again.
On Fri, 15 Jun 2007, Greg KH wrote:
> Oh great, then things like source code control systems would have no
> problems with new files being created under them, or renaming whole
> trees.
It depends -- I think we may be talking about different things.
If you're using inotify to watch for new files
On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:
> on the contrary, useing 'mv' is by far the cleanest way to do this.
>
> mv htdocs htdocs.old;mv htdocs.new htdocs
>
> this makes two atomic changes to the filesystem, but can generate thousands to
> millions of permission changes as a result.
OTOH
On Fri, 15 Jun 2007, Seth Arnold wrote:
> > How does inotify not work here? You are notified that the tree is
> > moved, your daemon goes through and relabels things as needed. In the
> > meantime, before the re-label happens, you might have the wrong label on
> > things, but "somehow" SELinux a
On Fri, 15 Jun 2007, Seth Arnold wrote:
> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.
restorecon can most definitely be improved.
- James
--
James Morris
<[EMAIL P
--- James Morris <[EMAIL PROTECTED]> wrote:
> On my system, it takes about 1.2 seconds to label a fully checked out
> kernel source tree with ~23,000 files in this manner
That's an eternity for that many files to be improperly labeled.
If, and the "if" didn't originate with me, your policy is
d
On Fri, 15 Jun 2007, Casey Schaufler wrote:
>
> --- James Morris <[EMAIL PROTECTED]> wrote:
>
> > On my system, it takes about 1.2 seconds to label a fully checked out
> > kernel source tree with ~23,000 files in this manner
>
> That's an eternity for that many files to be improperly labeled.
On Fri, Jun 15, 2007 at 09:21:57PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > Oh great, then things like source code control systems would have no
> > problems with new files being created under them, or renaming whole
> > trees.
>
> It depends -- I think we may be tal
37 matches
Mail list logo
