All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Masover <ninja@slaphack.com>
To: Nate Diller <ndiller@namesys.com>
Cc: Hans Reiser <reiser@namesys.com>,
	reiserfs-list@namesys.com,
	Reiserfs developers mail-list <Reiserfs-Dev@namesys.com>
Subject: Re: Mask moderation policy
Date: Fri, 08 Apr 2005 18:35:43 -0500	[thread overview]
Message-ID: <4257154F.7010700@slaphack.com> (raw)
In-Reply-To: <4255E152.3060808@namesys.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nate Diller wrote:
> Hans Reiser wrote:
> 
>> Nate, give them the code, and use the latest text we wrote for the
>> moderation policy guidelines.
>>
>>  
>>
> Ok guys, if you want the patch (and weren't clever/motivated enough to
> find it from the security_mask page source ;), go to
> www.namesys.com/mask/linux-2.6.12-rc1-mm1/maskb6.patch.   'Course no
> warranty, buggy as hell, yada yada...
> 
> The latest version of the moderation document that Hans mentioned is
> attatched.  I call it the God version, because it basically says we
> don't need any input from people like you anyway, we just appoint a
> benevolent dictator instead.  So give us feedback as to which policy is
> better, cause if you pick this version, it's the last input you get
> <laughs maniacally>

Just read http://www.namesys.com/blackbox_security.html

Sorry I'm so late on input, but I've had hell from school and no time to
read Namesys papers until now.

Can't find anything about user-specific masks.

This would be very useful -- the ability to apply a mask to an entire
user, or to apply different masks to the same executable based on which
user called that executable.

It would also be useful to have (the option of) exclusive masks as well
as inclusive masks.  For example, we might want to allow access to
everything in /home except for one specific user, or everything in /dev
except one specific person.

It'd also be nice to have an option of masks which apply to all
executables except one, or all users except one.  For instance, a
chroot'ed environment could be excluded from all programs except
/bin/chroot.

In fact, now that I think about it, the masks should probably be
plugan-ized a bit, such that every time a program tries to access a
file, the filename must be okayed by the mask plugin, then by the file's
own security plugins.  Directory listings may be filtered or denied
(not-found or permission denied) the same way -- program's mask plugin,
then file's security plugin.

Or could this be done in existing security plugins?  Am I correct in
thinking that when a file is accessed, the file's security plugin (not
the program's) is called?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQlcVT3gHNmZLgCUhAQJLhw/+PFjlsLT+QM40EELmcIAgRuAmnjjLWw3S
q6shlPtpE+HZdpyGurzf0leUdPUZStWHlXteV3Hbz2n5NknzmCsQni9D180mJMMj
ommDX2YReeTV4DN9FsfJAxG70zVvINAVj3o3BN1ZcYtWqCYn1jsX88UQzOiX68lK
1elJ4leV6abNf4fRY6m02i9ONu3UvwMQsD2wAqVm3lgxA1H8wJjwgj3alhQ7lmSQ
ZOw6uHKVrppDvxtTbnUxrT//yj23qE886Ja7z7t/NeesNSabp6nTxnD5ME/w5a1U
XV3gLeApAptGJvJ355OGZGQflmYQwuMlnxl0QqJ7luVfhT0c8UIZdY+BbR5tNG2G
QL8guUB/4MhkPLzGzVGMVBtdqtGkA0q0uF/rpKu/Un+ywfnSgynrNfRaHGqsKgRO
o+TJQD40deLpwb9Yog1ymEf6xMwl3KaMIgYJScE0VMx2Jxg4aBdcJl5IJw9Ud1w3
gCArpaF7BSdV4t98K1PKqcRcr2Kh495hEPijeWNXXLtQPJTVlIMbfxXrb9kgZclI
0UAXUh+MMIcx+Oa/mP0P0iqjvGAO7bHYBpipUUcSFxlPm7nqfkikNPHXA6IpKoCU
X4G9n43t/0r5CskZhf7fF/gpdqvtwuAqthgB1UQ4GmGUXfWbXdYj3kJy8xFZakvj
L34d72FlgKg=
=LDZQ
-----END PGP SIGNATURE-----

  reply	other threads:[~2005-04-08 23:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-07  7:51 Mask moderation policy Nate Diller
2005-04-07 19:25 ` Hans Reiser
2005-04-08  1:41   ` Nate Diller
2005-04-08 23:35     ` David Masover [this message]
2005-04-09  7:29       ` mjt
2005-04-10 17:18         ` David Masover
2005-04-10 20:21           ` mjt
2005-04-10 21:43             ` Nate Diller
2005-04-10 22:21             ` David Masover

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=4257154F.7010700@slaphack.com \
    --to=ninja@slaphack.com \
    --cc=Reiserfs-Dev@namesys.com \
    --cc=ndiller@namesys.com \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.