Mask moderation policy

Mask moderation policy

[Nate Diller]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

In accordance with the DARPA security masking proposal located at 
www.namesys.com/blackbox_security.html, we have constructed a moderation 
policy for future construction of masks.  Full details on the goals of 
the project can be found at the URL above, and we are perhaps two weeks 
away from an initial public beta release of the current implementation.  
A description of the functionality can be found at 
www.namesys.com/security_mask.html.  Briefly, the term 'mask' refers to 
a specification of which files in the system namespace a particular 
process is allowed to access.  This is similar to a chroot() jail, 
except for the existence of fallthroughs, which allow access to entire 
subtrees with one entry in the specification.  We have also implemented 
simple methods for automatically constructing a specification by 
observing a program's behavior, and we plan to add an interactive 
interface providing direct control over a running process's access.  I'm 
afraid the security_mask document is out of date with regard to this 
access logging functionality, hopefully I will have had a chance to add 
it by the time you are reading this...

We feel that the attached policy is quite sufficient, since we have 
replaced the need for a complex policy with a powerful and simple 
implementation.  We would, however, like to solicit the input of 
everyone who has an interest in this security policy, to ensure that it 
meets your needs, as end users and security minded administrators.  
Although we are far ahead of schedule in having working code at this 
early date, we regret that we cannot yet provide the source for review 
as well.  Hopefully the online documentation will be good enough to 
enable you to contribute to this discussion.  Any feedback on the 
security_mask document is welcome as well.

Thanks

NATE

[-- Attachment #2: view_moderation --]
[-- Type: text/plain, Size: 3259 bytes --]

Since the mask implementation allows fallthrough directories, most programs
will be effectively masked with a small number of simple entries, less then 32
in many cases.  Furthermore, we have implemented two effective automation
methods for mask creation, and these will continue to be improved over time. 
Thus we can say that security masks will not require a complex moderation
policy, since the masks will be simple to generate and their correctness will
be easy to verify using 'ls -R'.

Namesys will create a website and mailing list dedicated to creating and
testing masks.  The list and website will be moderated by a single security
professional, since it is expected that many masks will be trivial to verify. 
The non-trivial masks will be evaluated by interested groups on the mailing
list, and the moderator will have authority over the final mask or masks posted
to the site.  A masking policy will tend to be preferred if it restricts access
more tightly and has been tested to ensure that the program can still run
vieunhindered.

The site will include the capability for users to register as moderators, and
display their security credentials and clearances.  These moderators can
provide additional opinions on the effectiveness of the masks, to increase
confidence in the posted versions.  The site will also include tracking for
various versions for non-standard distributions or use cases.

The ideal solution for complex masks would be a set of policies created and
maintained by the program's user and developer community.  Such a policy could
be integrated into the installer script to seamlessly match the local
configuration. Since this is not realistic for the near-term, complex masks
will be maintained on the website, and will target the Debian distribution. 
Security minded distributions could modify and enhance the reference mask for
their own purposes, otherwise this task would be left to the users.

How complex this needs to be in practice can only be known with experience and
scaling.  In Phase II it probably will be wise for us to assign one person the
task of systematically masking all of the most common network service
providing processes, and contacting distros for participation in their betatest
programs.  We will then start soliciting the participation of others, and that
participation will need moderating.  It is not clear yet how substantial that
moderation will really need to be, and it is always risky to solve problems
whose substantiality has not yet been observed.

After masks become sufficiently widely used, and critical mass is reached,
their incorporation by the package maintainers and distros will become
routine.  In the early stages some distros may move more quickly than package
maintainers and try to get competitive advantage by masking all of their
network service providing processes. There seems to be enough market pressure
in the security area that being able to say that all of their network services
are masked will incentivise distros doing it even in the early stages.  Package
maintainers, because they will not control whether their users have masking
available, and because they are large in number and thus more work for us to
contact, will likely be last to adopt masks.

Re: Mask moderation policy

[Hans Reiser]

Nate, give them the code, and use the latest text we wrote for the
moderation policy guidelines.

Re: Mask moderation policy

[Nate Diller]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

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>

I still haven't had a chance to document the accessed/denied logging 
feature, so here it is:  create the directory [exe].accessed to have it 
fill in the paths of everything the program tried to access that the 
mask let through, and [exe].denied for everything it tried to access 
that the mask didn't allow.

Enjoy

NATE

[-- Attachment #2: god_moderation_policy --]
[-- Type: text/plain, Size: 1971 bytes --]

Since we suspect one person working full-time during Phase II could generate
masks for all significant Linux applications and all distros, the web of trust
and critical mass issues may turn out to be trivial.  This person hired for
Phase II should get a security clearance.

We propose the following mechanism:  for each distro there shall be a (not
necessarily unique) masks maintainer.   For each package maintainer there shall
be a (not necessarily unique) masks maintainer who creates at least one mask
valid for at least one distro.  There shall be a website on which all masks are
placed.

Distro masks maintainers are appointed by the distro.  Those distros who desire
to be accepted by the Department of Defense should use persons trusted by the
Department of Defense, or alternatively, the Department of Defense should use
its own personnel for that purpose.  Distro masks maintainers shall convert
masks from those created by the package mask maintainer to one effective for
their distro.  Scripts will be developed to suggest conversions.

It seems likely that in Phase II we could hire one person to create a mask for
every major package in Linux.  It just is not that much work when you have a
tool for doing it, and of course, if one person can do the job, the web of
trust and initial critical mass issues become pleasantly trivialized. 
Integrating those masks with individual distros should be done by those distros
other than Debian because usually only they can participate in their last
minute QA process.  We are likely to offer to provide a masks expert consultant
to each distro for a modest fee though.

In sum, we hope that by providing effective automation, and making an effort to
be of service to the community, this issue becomes trivialized for all packages
sufficiently standard that they come with a distro, and a reasonable task for
administrators to perform for those packages that are bought separately from a
distro or are home grown.

Re: Mask moderation policy

[David Masover]

-----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-----

Re: Mask moderation policy

[mjt]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

On Fri, Apr 08, 2005 at 06:35:43PM -0500, David Masover wrote:

[i.agree.snip]

A bit of philosophizing and thinking out loud ensued:

>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?

Wouldn't it be easiest to skip the idea of a file in exe.mask
as a fallthrough and have everything as directories?

$ mkdir -p bash.mask/dev/input/mouse0
$ # The directory will be visible
$ cat >> bash.mask/dev/input/acl
> allow group all
> allow user all
>EOF
$ # Then we set an acl of sorts on the mouse device
$ cat >> bash.mask/dev/input/mouse0/acl <<EOF
>deny group all
>allow group mouse
>allow user ninja, mjt
>EOF
$ # You have to be in the mouse group and run bash to see /dev/input/mouse0

But how should it be handled when something runs under bash?
Should bash deny all and /usr/sbin/gpm.mask/dev/input/mouse0 allow
the mouse group to access?

I suppose exclusive masks could also be seen as somewhat redundant, as
everything is denied by default, so masks could be handled by careful
per-group and -user allows..

Another issue with this is the amount of text parsing the above example
has to do. How to handle corrupt lines? Missing users?
if (!S_ISDIR(dentry->d_inode->i_mode)) is a lot lighter than the acl
parsing..

If this were implemented by extending what we have now; a file means
absolute fallback, a directory absolute visibility and no exclusions,
I believe the following might work.

touch bash.mask/dev/input/mouse0/mouse would allow the mouse group
to see the file. As I have zero experience in kernel code, I have none
to even pseudo here, but just check if "mouse" is a valid group..

This could be extended further with a scheme as follos:
$ find bash.mask/dev/input/mouse/
bash.mask/dev/input/mouse/group/mouse
bash.mask/dev/input/mouse/user/ninja
bash.mask/dev/input/mouse/user/mjt
$

Just two cents or something..

And great work, Namesys guys!

-- 
mjt


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mask moderation policy

[David Masover]

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

Markus Törnqvist wrote:
> On Fri, Apr 08, 2005 at 06:35:43PM -0500, David Masover wrote:
> 
> [i.agree.snip]
> 
> A bit of philosophizing and thinking out loud ensued:
> 
> 
>>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?
> 
> 
> Wouldn't it be easiest to skip the idea of a file in exe.mask
> as a fallthrough and have everything as directories?
> 
> $ mkdir -p bash.mask/dev/input/mouse0
> $ # The directory will be visible
> $ cat >> bash.mask/dev/input/acl
> 
>>allow group all
>>allow user all
>>EOF
> 
> $ # Then we set an acl of sorts on the mouse device
> $ cat >> bash.mask/dev/input/mouse0/acl <<EOF
> 
>>deny group all
>>allow group mouse
>>allow user ninja, mjt
>>EOF
> 
> $ # You have to be in the mouse group and run bash to see /dev/input/mouse0
> 
> But how should it be handled when something runs under bash?
> Should bash deny all and /usr/sbin/gpm.mask/dev/input/mouse0 allow
> the mouse group to access?

/usr/sbin/gpm.mask/dev/input/mouse0 allows it, and bash denies it.

Basically, a deny takes precedence.  If something isn't explicitly
allowed somewhere, it's denied.  What I'm saying is that it should be
possible to explicitly allow '*', and then explicitly deny things that
you don't want.

That's to maintain sanity when you don't have the entire distro cooperating.

> I suppose exclusive masks could also be seen as somewhat redundant, as
> everything is denied by default, so masks could be handled by careful
> per-group and -user allows..

What I mean is, there should be an option to deny-by-default or
allow-by-default.  If we're doing this on the user, for instance:

echo policy allow > /etc/passwd/.../ninja/mask
echo deny > /etc/passwd/.../ninja/mask/home/samurai

This gives ninja access to everything except /home/samurai.  In
practice, it'd probably be more like:

echo policy allow > /etc/passwd/.../ninja/mask
echo policy deny > /home/samurai/.../mask
echo allow samurai >> /home/samurai/.../mask

In the second example, ninja is denied from /home/samurai because the
/home/samurai mask is more specific, and they are both policies.  In
general, the more specific restrictions win, and all others being equal,
"deny" wins.

What I'm not sure about is how to bring back a true root shell.  In the
above example, the third command would fail, because /home/samurai would
be invisible to everyone (policy deny) and so no one would be able to
set its mask.

Maybe a "god" flag of some sort?

echo god root > /bin/bash/.../mask

So that when root runs bash, it and any programs launched by it are able
to view all files.  Sometimes that's not what you want, so you add a
program which drops "god" status.  For example:

$ ls /home/samurai
bin maildir
$ incarnate ls /home/samurai
ls: /home/samurai: No such file or directory
$ ls /home/samurai
bin maildir

(Incarnate is pseudocode.  Call it avatar, call it mortal, whatever.)

> Another issue with this is the amount of text parsing the above example
> has to do. How to handle corrupt lines? Missing users?

Corrupt lines return an error.  It might be a wierd error (I/O or
out-of-space,  for instance), but it'd be an error.  That's also how you
prevent users who own a file from making it invisible to root, which is
annoying even with the god flag.

Missing users is the same thing.  Once it gets parsed, we can turn it
into a UID anyway.  We could even link every acl that lists a user to
the /etc/passwd file somehow (in metadata, automatically) so that when
we remove a user, we can easily delete all acls which mention them.

> if (!S_ISDIR(dentry->d_inode->i_mode)) is a lot lighter than the acl
> parsing..

Only has to be done while it's set, and it could concievably be done in
userspace (perl, anyone?).  We're talking about the initial parsing,
right?  It could be optimized, but are people really going to be
changing their mask acl's 100 times a second?

Also, I'm not opposed to doing this all with files/dirs, if you can find
a good, clean way to do so.  It's worth wasting a few CPU clock cycles
and sparing a few end-user brain cycles.

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

iQIVAwUBQllf4ngHNmZLgCUhAQJTjQ/9H3DM1PjmkkfXrDVRrTaXvPSiWuO4z0wI
Kngj8mJSfNlk8rAmlVo9jZ3s5yxwHFkfphnLN4lY4bwNUvqLvbIHaoA42AgqDqEb
RfcOgcJy0RUq9u7g9GaJTHGnbztNKd/bii+r1fyVvGZGVSWavIrqqLYs4m5qaK5Y
JIaZ4HP5KRnK6qiQ2HdeoHKV54mjRyDOBSGnxQiRevWx94vyX1Mur7B4rp6JETeG
vvhPc/Xx3MwMwGXeE1kAa4TmYtDsU4yBMVDV9+QwYcsya5sCAzwXrIrzHC0P393X
SN8ki2Jww8T1gLb9rmtFLCRpTNde9IdWzKamh7DV+3+kigukycRmqxIF+MF3K2ID
F1lcSPJ6T7U2YAfZtNblRLZhxMIlv+KSYtgTNB7SSFkRya/7UCDLZ2R9TXUfwQAb
Edn32zZDcwlVif9BTmNylwgSu81/YgqGEEQBBDgybBYo9Ndjzk8Z0ZfSnzDF3PqB
6G3SB75zJI3KC8HyYFOJODJdQXyG/jovzsHsz1O+oTPIf/HfzCJf0u+qMTabnV4m
XoneFEhMxMdb+JdPo7WMNm3PJH5OxdXVaVljuEBBDkLe3HPSRwHgWz/BIrAshmBo
chKeavUeMgotcytR0YhW9AWe/iUfQt4bGLHGLcBnSl3LCBdnICN+MjRvqbj08Kjs
y1slJ/fVmzk=
=miG/
-----END PGP SIGNATURE-----

Re: Mask moderation policy

[mjt]

[-- Attachment #1: Type: text/plain, Size: 8540 bytes --]

On Sun, Apr 10, 2005 at 12:18:26PM -0500, David Masover wrote:

This email goes un-proof-read, I'm too far asleep now :)

>/usr/sbin/gpm.mask/dev/input/mouse0 allows it, and bash denies it.
>
>Basically, a deny takes precedence.  If something isn't explicitly
>allowed somewhere, it's denied.  What I'm saying is that it should be
>possible to explicitly allow '*', and then explicitly deny things that
>you don't want.

What about still skipping file parsing:
# Every group is denied, as they and users are by default (?)
$ mkdir -p /bin/bash.mask/dev/input/mouse0/group_deny/

# Every user is allowed (Big-ass contradiction, but users apply still here)
$ mkdir /bin/bash.mask/dev/input/mouse0/user_allow/

# Only mjt is allowed (Cutting down on the contradiction ;)
$ touch /bin/bash.mask/dev/input/mouse0/user_allow/mjt 

Then we want gpm to see the device, _as long as it's run with group mouse_:
# Ensure this is possible at all
$ mkdir -p /usr/sbin/gpm.mask/dev/input/mouse0/group_allow

# And then constraint gpm runs as group mouse:
$ touch /usr/sbin/gpm.mask/dev/input/mouse0/group_allow/mouse

This example is a bit fishy, as it's so closely tied to the end-user;
the mjt user will use the mouse regardless of what, because his box
boots up, starts gpm, with the mouse group, and can access the mouse
device via all this.

What does Namesys think; Should it be strictly per-process? Is any of this
user/group stuff here even remotely wanted?

>That's to maintain sanity when you don't have the entire distro cooperating.

Or on any desktop. I think it's a lot easier always to enable everything
by default and then deny.

So just for each binary you create the mask directories (later a reiser4
meta entries) group_allow and user_allow, then explicitly create
group_deny and user_deny to return priority to the denys and only then
start slamming in things like 
/usr/sbin/apache2.mask/etc/passwd/user_deny/www-data

But I'm tired and have the flu so I may not be thinking straight.

In fact, this should be a bit more like it is now..
At the moment a file means total fallthrough, a directory represents a file.

/path/to/exe.mask/[mask_mode]/(optional_specification)/masked/path/

In that scheme 
/masked/path/foo/bar
/masked/path/AAAAA/BBBB
and friends would adhere to whatever mask_mode (eg. allow_user)
and optional_specification (ninja) are set to.

/path/to/exe.mask/user_allow/ninja/masked/path/

/masked/path would then not be visible to mjt, as it's denied by default
and he could be given access to /masked/path/AAAAA/ by branching the
mask tree off at exe.mask/user_allow.

/path/to/exe.mask/user_allow/mjt/masked/path/AAAAA

Thank god this is only used for a few pieces of software, most of this
is pretty much like the basic security model we already have :)

>What I mean is, there should be an option to deny-by-default or
>allow-by-default.  If we're doing this on the user, for instance:

I like that.
What do you think of my idea to make allow-by-default allowable with
an mkdir? That seems to me like an easy way to avoid the issue.

$ mkdir -p /bin/bash.mask/user_allow/ # everyone sees everything through bash.

>echo policy allow > /etc/passwd/.../ninja/mask

What does this line exactly do? :P

>echo policy deny > /home/samurai/.../mask
>echo allow samurai >> /home/samurai/.../mask

For which process is this? Bash still? looks a bit more like generically
ACL'ing the current security model...

>In the second example, ninja is denied from /home/samurai because the
>/home/samurai mask is more specific, and they are both policies.  In
>general, the more specific restrictions win, and all others being equal,
>"deny" wins.

This is true, this is how it should be.
Let's get back later in the message on text file parsing :>

>What I'm not sure about is how to bring back a true root shell.  In the
>above example, the third command would fail, because /home/samurai would
>be invisible to everyone (policy deny) and so no one would be able to
>set its mask.

Haa! Yes! And giving root immunity in this is a very nasty idea, as many
exploits in servers work through the root user.

I'm too tired to think of any workaround now :P

>Maybe a "god" flag of some sort?
>echo god root > /bin/bash/.../mask

The "nikita" flag, god@laputa ;)

>So that when root runs bash, it and any programs launched by it are able
>to view all files.  Sometimes that's not what you want, so you add a
>program which drops "god" status.  For example:

What if it were the other way around?

(Above example stubbornly rewritten to my syntax and bash)

This is by default as well, but let's play for a while that we allowed
someone and did this and then started a new bash after this command.
$ mkdir /bin/bash.mask/user_deny/home/samurai
$ /bin/bash
bash: could not chdir to $HOME, using / instead
$ mkdir /bin/bash.mask/user_allow/samurai/home/samurai/
mkdir: cannot create directory /bin/bash.mask/user_allow/samurai/home/samurai:
No such file or directory

Oh dear!

We can't go home and we can't set the mask either.
One really really really important question here is,
WHAT THE HELL KIND OF A RIGHT DOES THE USER HAVE TO GROPE AT A SYSTEM
BINARY'S INTERNALS IN THE FIRST PLACE?!

He sees in /bin/bash.mask/ _only the files /bin/bash.mask allows_?

This is too much for me, let's get back on this some other day.
A case like this should not arise in any case.

>$ ls /home/samurai
>bin maildir
>$ incarnate ls /home/samurai
>ls: /home/samurai: No such file or directory
>$ ls /home/samurai
>bin maildir

In this case is incarnate a userspace program, a kernel interpretation
in execsomething() or a shell alias or what?

What about having it the other way around?
The root user can say:
$ ls /home/samurai
ls: /home/samurai: No such file or directory
$ omnipotent ls /home/samurai
bin maildir pr0n

And that's it. But how do we protect omnipotent here?

>Corrupt lines return an error.  It might be a wierd error (I/O or
>out-of-space,  for instance), but it'd be an error.  That's also how you

Maybe 666 Corrupt line?
It really sucks to return an error that's "close enough maybe if you
know what I mean"

>prevent users who own a file from making it invisible to root, which is
>annoying even with the god flag.

So, uhh, a corrupt line hides everything from root?
Even in your incarnate scheme I don't see how this is, sorry.

>Missing users is the same thing.  Once it gets parsed, we can turn it
>into a UID anyway.  We could even link every acl that lists a user to

Bad user, ret = -1, -1 != current_uid
And there we have it. woohoo \:D/

>the /etc/passwd file somehow (in metadata, automatically) so that when
>we remove a user, we can easily delete all acls which mention them.

That's actually not so bad an idea.

But this I believe is something where a directory-based scheme is
easier. What if we have a UserObject and a DirectoryObject that
were .. err.. cast or something, inexchangeably?

Might still lead to some weird problems for a later time, but possible
better than compiling ACL's. Maybe. But ACL's are greppable with ease.
I dunno.

>> if (!S_ISDIR(dentry->d_inode->i_mode)) is a lot lighter than the acl
>> parsing..
>Only has to be done while it's set, and it could concievably be done in
>userspace (perl, anyone?).  We're talking about the initial parsing,

The acl parsing? But how would the kernel remove that perl's result
from readdir() or somesuch?

>right?  It could be optimized, but are people really going to be
>changing their mask acl's 100 times a second?

This is also correct.

So, which is lighter? Once caching all ACL's into memory and keeping them
there or doing more S_ISDIR lookups?
I'd almost tend to agree with you, but I don't really like that idea :)

What about memory reservation? Some people claim Reiser4 is already
a bit too cpu-intense, what if it becomes memory-intense as well?

>Also, I'm not opposed to doing this all with files/dirs, if you can find
>a good, clean way to do so.  It's worth wasting a few CPU clock cycles
>and sparing a few end-user brain cycles.

I think you mean "we", and not just the two of us ;)
The same goes for text file parsing and syntax ;)

Hope this catches someone's interest, I'd hate for this idea-bouncing
to be between the two of us and later buried.

Nate? Zam? Hans? Anyone?

Thanks!

-- 
mjt


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mask moderation policy

[Nate Diller]

heh, I guess moderation policy discussions are less interesting than 
arguing over semantic interfaces :)

Markus Törnqvist wrote:

>On Sun, Apr 10, 2005 at 12:18:26PM -0500, David Masover wrote:
>
>This email goes un-proof-read, I'm too far asleep now :)
>
>  
>
>>/usr/sbin/gpm.mask/dev/input/mouse0 allows it, and bash denies it.
>>
>>Basically, a deny takes precedence.  If something isn't explicitly
>>allowed somewhere, it's denied.  What I'm saying is that it should be
>>possible to explicitly allow '*', and then explicitly deny things that
>>you don't want.
>>    
>>
>
>What about still skipping file parsing:
># Every group is denied, as they and users are by default (?)
>$ mkdir -p /bin/bash.mask/dev/input/mouse0/group_deny/
>
># Every user is allowed (Big-ass contradiction, but users apply still here)
>$ mkdir /bin/bash.mask/dev/input/mouse0/user_allow/
>
># Only mjt is allowed (Cutting down on the contradiction ;)
>$ touch /bin/bash.mask/dev/input/mouse0/user_allow/mjt 
>
>Then we want gpm to see the device, _as long as it's run with group mouse_:
># Ensure this is possible at all
>$ mkdir -p /usr/sbin/gpm.mask/dev/input/mouse0/group_allow
>
># And then constraint gpm runs as group mouse:
>$ touch /usr/sbin/gpm.mask/dev/input/mouse0/group_allow/mouse
>
>This example is a bit fishy, as it's so closely tied to the end-user;
>the mjt user will use the mouse regardless of what, because his box
>boots up, starts gpm, with the mouse group, and can access the mouse
>device via all this.
>
>What does Namesys think; Should it be strictly per-process? Is any of this
>user/group stuff here even remotely wanted?
>
>  
>
>>That's to maintain sanity when you don't have the entire distro cooperating.
>>    
>>
>
>Or on any desktop. I think it's a lot easier always to enable everything
>by default and then deny.
>
>So just for each binary you create the mask directories (later a reiser4
>meta entries) group_allow and user_allow, then explicitly create
>group_deny and user_deny to return priority to the denys and only then
>start slamming in things like 
>/usr/sbin/apache2.mask/etc/passwd/user_deny/www-data
>
>But I'm tired and have the flu so I may not be thinking straight.
>
>In fact, this should be a bit more like it is now..
>At the moment a file means total fallthrough, a directory represents a file.
>
>/path/to/exe.mask/[mask_mode]/(optional_specification)/masked/path/
>
>In that scheme 
>/masked/path/foo/bar
>/masked/path/AAAAA/BBBB
>and friends would adhere to whatever mask_mode (eg. allow_user)
>and optional_specification (ninja) are set to.
>
>/path/to/exe.mask/user_allow/ninja/masked/path/
>
>/masked/path would then not be visible to mjt, as it's denied by default
>and he could be given access to /masked/path/AAAAA/ by branching the
>mask tree off at exe.mask/user_allow.
>
>/path/to/exe.mask/user_allow/mjt/masked/path/AAAAA
>
>Thank god this is only used for a few pieces of software, most of this
>is pretty much like the basic security model we already have :)
>
>  
>
And you've just answered your earlier question.  This model is useful 
only to the degree that it acts independent of the userID priveleges of 
the process, since there is already a mechanism for discriminating based 
on user/group.  The key to masking's usefulness is that you can't gain 
root to get around it.

That said, a full-fledged implementation of views would surely have to 
take some user-specific data into account, but it remains to be seen how 
the interface for this should be constructed.  A reasonable 
implementation might use environment variables for user-specific views, 
adding flexibility for the user.  Regardless, there is no reason to 
think that such a feature should be used for per-user security, since 
the user can simply execute their own copy of any program to get around 
such restrictions by the administrator on the 'official' binary.

>>What I mean is, there should be an option to deny-by-default or
>>allow-by-default.  If we're doing this on the user, for instance:
>>    
>>
>
>I like that.
>What do you think of my idea to make allow-by-default allowable with
>an mkdir? That seems to me like an easy way to avoid the issue.
>
>$ mkdir -p /bin/bash.mask/user_allow/ # everyone sees everything through bash.
>
>  
>
>>echo policy allow > /etc/passwd/.../ninja/mask
>>    
>>
>
>What does this line exactly do? :P
>
>  
>
>>echo policy deny > /home/samurai/.../mask
>>echo allow samurai >> /home/samurai/.../mask
>>    
>>
>
>For which process is this? Bash still? looks a bit more like generically
>ACL'ing the current security model...
>
>  
>
>>In the second example, ninja is denied from /home/samurai because the
>>/home/samurai mask is more specific, and they are both policies.  In
>>general, the more specific restrictions win, and all others being equal,
>>"deny" wins.
>>    
>>
>
>This is true, this is how it should be.
>Let's get back later in the message on text file parsing :>
>
>  
>
>>What I'm not sure about is how to bring back a true root shell.  In the
>>above example, the third command would fail, because /home/samurai would
>>be invisible to everyone (policy deny) and so no one would be able to
>>set its mask.
>>    
>>
>
>Haa! Yes! And giving root immunity in this is a very nasty idea, as many
>exploits in servers work through the root user.
>
>I'm too tired to think of any workaround now :P
>
>  
>
>>Maybe a "god" flag of some sort?
>>echo god root > /bin/bash/.../mask
>>    
>>
>
>The "nikita" flag, god@laputa ;)
>
>  
>
The way around this problem is simple.  If the super-user has created a 
mask for, say, the init process, there would be no way to access the 
denied paths while the system is running, or to delete the mask.  So 
simply boot a kernel without masking support.  (We could add a boot flag 
I suppose, but that's a low priority to me)

>>So that when root runs bash, it and any programs launched by it are able
>>to view all files.  Sometimes that's not what you want, so you add a
>>program which drops "god" status.  For example:
>>    
>>
>
>What if it were the other way around?
>
>(Above example stubbornly rewritten to my syntax and bash)
>
>This is by default as well, but let's play for a while that we allowed
>someone and did this and then started a new bash after this command.
>$ mkdir /bin/bash.mask/user_deny/home/samurai
>$ /bin/bash
>bash: could not chdir to $HOME, using / instead
>$ mkdir /bin/bash.mask/user_allow/samurai/home/samurai/
>mkdir: cannot create directory /bin/bash.mask/user_allow/samurai/home/samurai:
>No such file or directory
>
>Oh dear!
>
>We can't go home and we can't set the mask either.
>One really really really important question here is,
>WHAT THE HELL KIND OF A RIGHT DOES THE USER HAVE TO GROPE AT A SYSTEM
>BINARY'S INTERNALS IN THE FIRST PLACE?!
>
>He sees in /bin/bash.mask/ _only the files /bin/bash.mask allows_?
>
>This is too much for me, let's get back on this some other day.
>A case like this should not arise in any case.
>
>  
>
>>$ ls /home/samurai
>>bin maildir
>>$ incarnate ls /home/samurai
>>ls: /home/samurai: No such file or directory
>>$ ls /home/samurai
>>bin maildir
>>    
>>
>
>In this case is incarnate a userspace program, a kernel interpretation
>in execsomething() or a shell alias or what?
>
>What about having it the other way around?
>The root user can say:
>$ ls /home/samurai
>ls: /home/samurai: No such file or directory
>$ omnipotent ls /home/samurai
>bin maildir pr0n
>
>And that's it. But how do we protect omnipotent here?
>
>  
>
>>Corrupt lines return an error.  It might be a wierd error (I/O or
>>out-of-space,  for instance), but it'd be an error.  That's also how you
>>    
>>
>
>Maybe 666 Corrupt line?
>It really sucks to return an error that's "close enough maybe if you
>know what I mean"
>
>  
>
>>prevent users who own a file from making it invisible to root, which is
>>annoying even with the god flag.
>>    
>>
>
>So, uhh, a corrupt line hides everything from root?
>Even in your incarnate scheme I don't see how this is, sorry.
>
>  
>
>>Missing users is the same thing.  Once it gets parsed, we can turn it
>>into a UID anyway.  We could even link every acl that lists a user to
>>    
>>
>
>Bad user, ret = -1, -1 != current_uid
>And there we have it. woohoo \:D/
>
>  
>
>>the /etc/passwd file somehow (in metadata, automatically) so that when
>>we remove a user, we can easily delete all acls which mention them.
>>    
>>
>
>That's actually not so bad an idea.
>
>But this I believe is something where a directory-based scheme is
>easier. What if we have a UserObject and a DirectoryObject that
>were .. err.. cast or something, inexchangeably?
>
>Might still lead to some weird problems for a later time, but possible
>better than compiling ACL's. Maybe. But ACL's are greppable with ease.
>I dunno.
>
>  
>
>>>if (!S_ISDIR(dentry->d_inode->i_mode)) is a lot lighter than the acl
>>>parsing..
>>>      
>>>
>>Only has to be done while it's set, and it could concievably be done in
>>userspace (perl, anyone?).  We're talking about the initial parsing,
>>    
>>
>
>The acl parsing? But how would the kernel remove that perl's result
>from readdir() or somesuch?
>
>  
>
>>right?  It could be optimized, but are people really going to be
>>changing their mask acl's 100 times a second?
>>    
>>
>
>This is also correct.
>
>So, which is lighter? Once caching all ACL's into memory and keeping them
>there or doing more S_ISDIR lookups?
>I'd almost tend to agree with you, but I don't really like that idea :)
>
>What about memory reservation? Some people claim Reiser4 is already
>a bit too cpu-intense, what if it becomes memory-intense as well?
>
>  
>
>>Also, I'm not opposed to doing this all with files/dirs, if you can find
>>a good, clean way to do so.  It's worth wasting a few CPU clock cycles
>>and sparing a few end-user brain cycles.
>>    
>>
>
>I think you mean "we", and not just the two of us ;)
>The same goes for text file parsing and syntax ;)
>
>Hope this catches someone's interest, I'd hate for this idea-bouncing
>to be between the two of us and later buried.
>
>Nate? Zam? Hans? Anyone?
>
>Thanks!
>  
>
A glimpse into my ideas for improving the granularity, then...

As mentioned in namesys.com/security_mask.html, the original intention 
for the mask's root directory was the executable itself, in its Reiser4 
metas directory.  There were two difficulties with this approach, which 
caused us to settle for the ugly [exe].something hack.  First, 
file/directory duality needs changes to the dentry code to exist without 
fatal bugs, and second, creating and deleting normal files and 
directories is not currently supported in Reiser4 metas (I found this 
out the hard way: disable a few assertions and you can create some real 
wierdness with touch/mkdir in metas).

Fixing these two problems is on the agenda, although I cannot speculate 
where they fall in Hans' list of priorities.  Once duality is up and 
running, the plan was to have more information about a mask node in its 
file section, so that each component of a path in the mask can be more 
specific about what it allows/denies.  As in:

mkdir -p bash.mask/home/nate/
echo 'deny */.*' > bash.mask/home

to prevent access to ~/.bashrc et al.  Don't consider this specific 
functionality to be anything but a quickly composed example, since it is 
likely that denials will have their own tree, as in

touch bash.allow/home/nate
touch bash.deny/home/nate/private

or something.  But that's the general idea, allow finer granularity by 
specifying it within the mask directory's component data streams.

NATE

Re: Mask moderation policy

[David Masover]

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

Markus Törnqvist wrote:
> On Sun, Apr 10, 2005 at 12:18:26PM -0500, David Masover wrote:
> 
> This email goes un-proof-read, I'm too far asleep now :)
> 
> 
>>/usr/sbin/gpm.mask/dev/input/mouse0 allows it, and bash denies it.
>>
>>Basically, a deny takes precedence.  If something isn't explicitly
>>allowed somewhere, it's denied.  What I'm saying is that it should be
>>possible to explicitly allow '*', and then explicitly deny things that
>>you don't want.
> 
> 
> What about still skipping file parsing:
> # Every group is denied, as they and users are by default (?)
> $ mkdir -p /bin/bash.mask/dev/input/mouse0/group_deny/
> 
> # Every user is allowed (Big-ass contradiction, but users apply still here)
> $ mkdir /bin/bash.mask/dev/input/mouse0/user_allow/
# I'd make it
$ touch /bin/bash.mask/dev/input/mouse0/.../user_allow/all


I'm accepting the bash.mask, though that should really be bash/.../mask,
but suppose a program wants to allow its group (say gpm wants to allow
mouse) regardless of what the policy is (allow-by-default or
deny-by-default).  If an empty user_allow is allow-by-default, the
program will inadvertently change it to deny-by-default, while what it
wanted to do was add a redundant allow.

That's the logic behind my next comment:

> # Only mjt is allowed (Cutting down on the contradiction ;)
> $ touch /bin/bash.mask/dev/input/mouse0/user_allow/mjt 

No, that shouldn't be it.  That should specify that user mjt is allowed.
 If you want ONLY mjt to be allowed, you should have to
$ touch /bin/bash.mask/dev/input/mouse0/.../user_deny/all

If you want, replace "all" with something that's not likely to be a
username, or isn't an alowed username.  Usernames probably aren't
allowed to have colons in them, for example.  I think "all" is fine.

> This example is a bit fishy, as it's so closely tied to the end-user;

Not just because of that.  You don't seem to have the inheritance
spelled out clearly there.  For instance, user should be more specific
than group -- it should be possible to explicitly deny group "users",
and then explicitly allow group "mjt".

> What does Namesys think; Should it be strictly per-process? Is any of this
> user/group stuff here even remotely wanted?

More importantly, does Namesys have a better way of achieving the same
effect with only per-process views?

There's no question whether it's wanted.  I'm a user, and I want it.
It's a good feature, and it logically makes sense.  But we've been
hacking pseudocode for less than a day on this.  Maybe Namesys has some
better design ideas?

>>That's to maintain sanity when you don't have the entire distro cooperating.
> 
> Or on any desktop. I think it's a lot easier always to enable everything
> by default and then deny.

Actually, I find it's easier to deny-by-default for some things.  I
don't run everything as root.  It'd take forever to enumerate all the
things I'd want to deny myself as a user, vs. occasionally allowing
something via sudo or chmod.

But, it's equally as difficult to figure out every single thing a given
binary needs to see (unless you already know), vs. finding something you
want to keep from that particular binary, or to hide from everyone.

> So just for each binary you create the mask directories (later a reiser4
> meta entries) group_allow and user_allow, then explicitly create
> group_deny and user_deny to return priority to the denys and only then
> start slamming in things like 
> /usr/sbin/apache2.mask/etc/passwd/user_deny/www-data
> 
> But I'm tired and have the flu so I may not be thinking straight.

apache2.mask should allow some things, actually.  Also, maybe
/etc/passwd contains a file called user_deny.  Best to be unambiguous.

Does apache2 drop permissions later?  Is that the point of this, that
Apache needs to see passwd until it drops permissions?

>>What I mean is, there should be an option to deny-by-default or
>>allow-by-default.  If we're doing this on the user, for instance:
> 
> 
> I like that.
> What do you think of my idea to make allow-by-default allowable with
> an mkdir? That seems to me like an easy way to avoid the issue.
> 
> $ mkdir -p /bin/bash.mask/user_allow/ # everyone sees everything through bash.
> 
> 
>>echo policy allow > /etc/passwd/.../ninja/mask
> 
> 
> What does this line exactly do? :P

I'm thinking that this /etc/passwd/.../ninja/mask is an ACL file
controlling a global mask for user ninja.  Basically, ninja is allowed
by default.  This applies to any binary running under user ninja,
because it's set in /etc/passwd, which seemed the logical place to set
global options for unix-like users.

Actually, now that I think of it, I should probably do:

echo allow ninja > /.../mask

This allows ninja access to anything in /, provided that a specific
program or subdirectory/file doesn't override that.

>>echo policy deny > /home/samurai/.../mask
>>echo allow samurai >> /home/samurai/.../mask
> 
> 
> For which process is this? Bash still? looks a bit more like generically
> ACL'ing the current security model...

Yes, only it's actually hiding the existance of the directory.  It also
allows bash to override that.  So, for example, suppose you've got a
database server -- let's say mysql -- with databases in /var/lib/mysql.
 In order to prevent people from screwing with mysql data, or attemting
to back it up in an inconsistent state, we do this:

##I'm using a new notation now.  Watch out for buggy pseudocode.
##Since we're creating a file, this denies everything, and programs
##can't accidentally change the policy by touching something inside.
$ touch /usr/bin/mysql/.../mask/deny
##Allow /var/lib/mysql to user mysql, since we're deny-by-default
$ mkdir -p /usr/bin/mysql/.../mask/allow_user/mysql/var/lib/mysql

I'm putting the allow_user bit in front of the path, because that way
the path can contain any wierd names in in that we like.  For example,
we could allow deal with paths like "/backup/mysql_mask/allow_user"...
With that scheme, the only path we can't deal with is ".", "..", or "..."

Now, every time mysql starts up, it does this:

$ touch /var/lib/mysql/.../mask/deny

And every time it shuts down properly, it does this:

$ rm /var/lib/mysql/.../mask/deny

This effectively blocks all binaries, users, and groups from accessing
/var/lib/mysql when mysql is running, unless they are the /usr/bin/mysql
binary, running as user mysql, or if they are /bin/bash (or spawned by
/bin/bash), running as root.

>>What I'm not sure about is how to bring back a true root shell.  In the
>>above example, the third command would fail, because /home/samurai would
>>be invisible to everyone (policy deny) and so no one would be able to
>>set its mask.
> 
> 
> Haa! Yes! And giving root immunity in this is a very nasty idea, as many
> exploits in servers work through the root user.

And many system administrators work through the root user.  You
demonstrate that below:

> I'm too tired to think of any workaround now :P

I did, see below:

>>Maybe a "god" flag of some sort?
>>echo god root > /bin/bash/.../mask
> 
> 
> The "nikita" flag, god@laputa ;)
> 
> 
>>So that when root runs bash, it and any programs launched by it are able
>>to view all files.  Sometimes that's not what you want, so you add a
>>program which drops "god" status.  For example:
> 
> 
> What if it were the other way around?
> 
> (Above example stubbornly rewritten to my syntax and bash)
> 
> This is by default as well, but let's play for a while that we allowed
> someone and did this and then started a new bash after this command.
> $ mkdir /bin/bash.mask/user_deny/home/samurai

Already wrong.  My syntax would deny ALL programs, and ALL users, unless
specifically allowed.

> $ /bin/bash
> bash: could not chdir to $HOME, using / instead
> $ mkdir /bin/bash.mask/user_allow/samurai/home/samurai/
> mkdir: cannot create directory /bin/bash.mask/user_allow/samurai/home/samurai:
> No such file or directory
> 
> Oh dear!
> 
> We can't go home and we can't set the mask either.
> One really really really important question here is,
> WHAT THE HELL KIND OF A RIGHT DOES THE USER HAVE TO GROPE AT A SYSTEM
> BINARY'S INTERNALS IN THE FIRST PLACE?!

The user is setting permissions on something they own.  That should be
on /home/samurai.mask, not /bin/bash.mask.  Samurai should be able to
block people from /home/samurai, to keep out us ninjas.  But if us
ninjas are too good for him -- one of us has a root account -- we should
be able to allow ourselves back in.

bash# touch /home/samurai/.../mask/user_allow/ninja

> This is too much for me, let's get back on this some other day.
> A case like this should not arise in any case.

Yes it should.  Look at the mysql example above.  It's reasonable to say
that only the mysql binary should be allowed to access /var/lib/mysql,
but root should be able to override that.  If mysql refuses to die, a
kill -9 will very likely not reverse the mask, and you'd have to use a
bootdisk of some sort, just to change a permission.

That's why there is a root user in the first place.

>>$ ls /home/samurai
>>bin maildir
>>$ incarnate ls /home/samurai
>>ls: /home/samurai: No such file or directory
>>$ ls /home/samurai
>>bin maildir
> 
> 
> In this case is incarnate a userspace program, a kernel interpretation
> in execsomething() or a shell alias or what?

All of the above.  Basically, we're assuming that if a program 'exec's
another program, the new program doesn't inherit any "allow"s.  So,
under normal circumstances, if we give bash a god flag, it only applies
to bash builtins

# echo /home/samurai/*
bin maildir
# ls /home/samurai
ls: /home/samurai: No such file or directory

Since the vast majority of commands run from a root prompt are simple
Unix-y things like ls, I'm saying that the god flag should pass from
parent process to child process unless the parent process explicitly
forbids it.

To make this simpler, I'm saying that incarnate should be a program
which launches another program (given to it in arguments), but forbids
it from having the god flag.  It would probably also be a bash builtin.

Actually, now that I think of it, it makes much more sense to make root
entirely immune to masks, and to have distros be rearranged such that
there is an administrative user who gets almost all the permissions that
root does.  Alternatively, we could make a super-root user (uid -1?)
which is allowed to do everything root does, plus bypass the masks.

In any case, saying that "most unix exploits are through root" doesn't
imply that root is a bad thing.  If they don't get you with root,
they'll get you with the kernel.  IMHO, it's far better to prevent them
from getting root -- have more things run as users with restrictive view
masks on -- than to limit root and thus limit your own effectiveness.

> What about having it the other way around?
> The root user can say:
> $ ls /home/samurai
> ls: /home/samurai: No such file or directory
> $ omnipotent ls /home/samurai
> bin maildir pr0n
> 
> And that's it. But how do we protect omnipotent here?

Can't.  You could prevent it from being run by anyone but root, but
that's not really much better.

>>Corrupt lines return an error.  It might be a wierd error (I/O or
>>out-of-space,  for instance), but it'd be an error.  That's also how you
> 
> 
> Maybe 666 Corrupt line?
> It really sucks to return an error that's "close enough maybe if you
> know what I mean"

True, but sometimes you have to if the interface is limited.  Suppose
can't do something like the above, maybe because we can only return an
error code up to 256, maybe because all the codes are spoken for, or
maybe because we'll be torn to deaths by conservatives for using the
number of the beast.  If we can't use a good error code, it's better to
just have some kind of fatal error (so the program doesn't think it
worked) and tell users to look at dmesg.

>>prevent users who own a file from making it invisible to root, which is
>>annoying even with the god flag.
> 
> 
> So, uhh, a corrupt line hides everything from root?
> Even in your incarnate scheme I don't see how this is, sorry.

No, a corrupt line fails AS YOU ADD IT, because ultimately this would be
done via meta-files.  It'd look and feel like a normal file, but as soon
as you try to write a syntax error to the file, you get an IO error or
something.

With the incarnate scheme, users can hide their files from everyone else
by setting file-specific but exe-generic masks.  But masks don't apply
to a root bash prompt.  If root wants to launch a server or see what it
looks like to not be god, they use "incarnate", but if they don't use
that command, then the masks get completely ignored, even if they are
somehow corrupt.

>>Missing users is the same thing.  Once it gets parsed, we can turn it
>>into a UID anyway.  We could even link every acl that lists a user to
> 
> 
> Bad user, ret = -1, -1 != current_uid
> And there we have it. woohoo \:D/

Again, not a problem with meta-files.  You get the same kind of error,
but you don't get it when the file is accessed, but rather when its mask
is set.

>>the /etc/passwd file somehow (in metadata, automatically) so that when
>>we remove a user, we can easily delete all acls which mention them.
> 
> 
> That's actually not so bad an idea.
> 
> But this I believe is something where a directory-based scheme is
> easier. What if we have a UserObject and a DirectoryObject that
> were .. err.. cast or something, inexchangeably?
> 
> Might still lead to some weird problems for a later time, but possible
> better than compiling ACL's. Maybe. But ACL's are greppable with ease.
> I dunno.

I like the directory scheme.  I'm beginning to think that ACLs should
just be a frontend to that -- in the same way that passwd could be a
frontend to a bunch of files.

>>>if (!S_ISDIR(dentry->d_inode->i_mode)) is a lot lighter than the acl
>>>parsing..
>>
>>Only has to be done while it's set, and it could concievably be done in
>>userspace (perl, anyone?).  We're talking about the initial parsing,
> 
> 
> The acl parsing? But how would the kernel remove that perl's result
> from readdir() or somesuch?

say what?

## I mean, this:
$ acl="policy such and such\nmore acl voodoo"
$ echo -e "$acl" > /some/where/.../mask_acl
## should do the same thing as this:
$ echo -e "$acl" | ./make_acl.pl /some/where

That is, unless I'm modifying a mask, perl isn't being run by the
kernel.  Now, what's that about readdir?

>>right?  It could be optimized, but are people really going to be
>>changing their mask acl's 100 times a second?
> 
> 
> This is also correct.
> 
> So, which is lighter? Once caching all ACL's into memory and keeping them
> there or doing more S_ISDIR lookups?
> I'd almost tend to agree with you, but I don't really like that idea :)
> 
> What about memory reservation? Some people claim Reiser4 is already
> a bit too cpu-intense, what if it becomes memory-intense as well?

It's not going to be memory-intensive, except when we want to change the
masks.  That's like saying that setacl or vim or mkdir are too
memory/cpu-intensive.  NO ONE'S GOING TO CARE if they actually
understand it.  Of course, if they misunderstand, they will think we're
bloated, so we'd better write good docs ;)

>>Also, I'm not opposed to doing this all with files/dirs, if you can find
>>a good, clean way to do so.  It's worth wasting a few CPU clock cycles
>>and sparing a few end-user brain cycles.
> 
> 
> I think you mean "we", and not just the two of us ;)
> The same goes for text file parsing and syntax ;)

Text file syntax can be as simple as I said -- three possible commands,
each takes one argument.  Or three variables, if you like.

Either way, it's a tiny Perl script to take my text files and make them
into your directories.  And it probably takes very little time to do the
S_ISDIR lookups (or maybe something that ends in EXISTS?) vs caching in
RAM, but I wouldn't know.

I know reiser4 theory, not source code, though that will change soon, I
think.  I'm thinking that I should do the offline resizer.  Right now,
we can't even expand reiser4 filesystems.  This is a bug.  And shrinking
them is theoretically simple enough that I'm foolish enough to take it
on over the summer.

> Hope this catches someone's interest, I'd hate for this idea-bouncing
> to be between the two of us and later buried.

Archived, I hope.  But maybe we should be a little less verbose?

As someone once said, "I wrote you a long paper because I didn't have
time to write you a short one."

> Nate? Zam? Hans? Anyone?

It's a weekend.  Have some patience.

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

iQIVAwUBQlmm3HgHNmZLgCUhAQJ59w/+IrdgC0Ia1es7yvRGYwuMIASYi6Feu5V8
ax5xQdoOAlxMz+q72AjZoCHDBIeRKa/XW+4y35uUozuIazapUQk4yKFH+ZOe6zYN
mUVRtNxoyqda6X87PC4mltJqNCp9jV7DOHEcPJetoMJ/9sWScqvkYBDgoBcJnjp2
kkyMMgr8nxCBYLvMiF8VarQcy4MeRlIOP6vl1RU96pFOcB3/jbSsVyKEz5KD6zvM
9Nad4qpvrTubTOEAMT4fGx7BtpmvykaN0l+RIXHT+Dei0vWX4PxjVpk5Vy0ISgI9
VTv5esju++O+CanPBrdmWmK6W+OVMbS6bUMMg0omILntJuSofBuBuXEeG882Vs0e
zYIOooIDRGPcE7vUmd4uQVYCn08Jvu3/M2gEHtcLD3tGMAGd2Qpy8Y6Mglju6gUB
nuNWp+Yek2Bs43EW+yeTQgWMpO3LiBX8DVv3orPRM/XLCazM15EYMR/K4yoCD4C/
L1mnRcLem4KXzusr3iEsmswKuzG6OQbyYDnY8hcpUOqqR8ewFOJ9Im4l3+M2XUCS
zN92933GEbX5dhhWFY1Bg1NctlTep76fed+wrdXZZw6pXs66pN8uXyLvAmHnLo8u
IB3bGU85Y5giJq17WhLfRJnFCw4nIC0BkomPJl+vo/8nl7JYuo5cyci13tHytqIv
a85hluQ1yc0=
=MDWn
-----END PGP SIGNATURE-----