mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bodo Eggert <7eggert@gmx.de>
To: Pavel Machek <pavel@ucw.cz>
Cc: Bodo Eggert <7eggert@gmx.de>, James Morris <jmorris@namei.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: TOMOYO in linux-next
Date: Mon, 30 Mar 2009 13:22:07 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LSU.0.999.0903301202330.4746@be1.lrz> (raw)
In-Reply-To: <20090329213955.GD31857@elf.ucw.cz>

On Sun, 29 Mar 2009, Pavel Machek wrote:

> 
> >>> How would you exclude mozilla from writing to .* then? ".a" is bad,
> >>> ".b" is bad ...? or "A" is OK, "a" is OK, "zzzzzzzzzzzzz" is OK"?
> >>> Either way, you'd need several universes to store the security profile.
> >>
> >> What is magic about .* files? I want mozilla to store the pictures as
> >> .naughty.picture.jpg -- I don't see anything wrong with that.
> >
> > As long as you have a guaranteed-to-be-complete list of config files, you 
> > can get along without wildcards. And still if you do, I'll write a 
> > program to make it incomplete.
> 
> Not all config files match .* pattern. I have at least hugo.ini
> mxmap.ini in my ~.
       ^^^^
I see a pattern there.

IMO there is no use in a security system if it allows you to modify 
something like ~/.bashrc, and a security system not allowing mozilla to 
create ~/.mozilla or ~/pr0n.jpg is not usable at all.

You must handle different files in one directory diffrerently, and since 
they are not there yet, you can't label them. Instead, you'll have to label 
them at runtime, and you have to do it based on the filename. At the same 
time, you have a HUGE number of problematic filenames and a HUGE number of 
safe filenames. Unless you have about 500 universes, you can't implement a 
bitmap of allowed an non-allowed filenames.

What will you do? Give up and let mozilla modify all the config files you 
didn't think of? Or not let mozilla store tux.png in ~?

-- 
Artificial Intelligence usually beats real stupidity.

  reply	other threads:[~2009-03-30 11:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ck5CF-5mU-11@gated-at.bofh.it>
2009-03-27  9:28 ` Bodo Eggert
2009-03-27 11:42   ` Pavel Machek
2009-03-27 13:04     ` Bodo Eggert
2009-03-29 11:58       ` Pavel Machek
2009-03-29 14:25         ` Bodo Eggert
2009-03-29 21:39           ` Pavel Machek
2009-03-30 11:22             ` Bodo Eggert [this message]
2009-03-26 21:50 Pavel Machek
2009-03-27  0:15 ` James Morris
2009-03-27  0:30   ` Pavel Machek
2009-03-27  0:51     ` James Morris
2009-03-27 11:36       ` Pavel Machek
2009-03-27  0:36   ` Pavel Machek
2009-03-27  0:46     ` James Morris
2009-03-27 11:35       ` Pavel Machek
2009-03-27  4:12   ` Tetsuo Handa
2009-03-27  8:04     ` James Morris
2009-03-27 11:40     ` Pavel Machek
2009-04-06 11:49     ` Tetsuo Handa
2009-04-06 12:01       ` Pavel Machek
2009-04-06 22:21       ` 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=alpine.LSU.0.999.0903301202330.4746@be1.lrz \
    --to=7eggert@gmx.de \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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®