On Thu, 25 May 2000, Linda Walsh wrote:
>A minor thorn.
>
>This is my belief about the 'access' system call: It seems the purpose
>was to decide if a given file was accessible by the 'real' user when
>running an 'suid' program.
>
>This implies that the 'euid' be saved off, the 'euid' should be set to
>the 'real uid' (uid) and then we check for access.
>
>I believe that the 'access' system call should check each pathname
>component to ensure the 'real uid' has at least 'x' for every pathname
>component except the last. (???)
Personally, I think this really calls for a different approach (a 2.5
implementation):
A mod to the VFS layer access call to allow a uid, gid array to be passed
to the FS interface for validation. Most of the time the parameters would
be the euid and normal gid array. Other times it might be different (the
program is running setuid/setgid).
Advantages:
1. the error prone "the 'euid' be saved off, the 'euid' should be set to
the 'real uid' (uid) and then we check for access" and then restore
the original euid... thing.
What happens if the activity is non-blocking? A second access/open
may be requested as the result of async I/O events...
2. The locks necessary to block access to the euid disappear.
3. It eliminates a function that is almost identical.
Disadvantage:
1. It Isn't The Way Things Are Done....
2. It introduces another change to the VFS
3. All file systems access function would be altered.
Anything else?
>Now, I throw in CAPABILITIES. Say I now run a "set-cap" program, but
>the program wants to use 'access' for the same semantic reason (to determine
>the process's access to a file before the new capabilities were enabled).
>
>This would imply the need for 1 of 2 checks:
>
> 1) check access with the process's Effective Caps *before* the
>program loaded it's caps,
>
> or
>
> 2) check access with the process's Permitted caps *before* the
>program loaded it's caps.
>
>
> I think 1) would be "safer", but either way implies the need
>for a "saved capability set". No?
Ummm. How about something similar to "geteuid/seteuid" thing that some setuid
programs do now? That way it would be up to the privileged application for which
way to test.
>My belief on executable inheritance rules are below:
>------------
>When a new program is loaded the inherited vector is set
>
> I-proc-new = I-file & I-proc-old
>
>the permitted vector is set
>
> P-proc-new = P-file | (P-proc-old & I-proc-new)
>
>the effective vector is set
>
> E-proc-new = E-file & P-proc-new
>
>The new inherited vector is the intersection of the process inherited vector and the program inherited vector.
>
>The new permitted vector is the union of the program permitted vector and the intersection of the new inherited vector and the process permitted vector.
>
>The new effective vector is the intersection of the new permitted vector and the program effective vector.
>----------
>
> Is this correct?
>
> These would be applied within the execX system call.
>
>I also anticipate the need for a 64 bit capability vector. Should we
>fold this in now? I can see (from POSIX 1003.1e DS15) some of the
>following needed caps (which is not to say this is an exhaustive list).
My opinion is definitly 64 bit (at a minimum). I do believe that some of them
should be set aside for site use (8-16 bits please). Applications could then use
these to determine subsets of actions that may be permitted in user space. The
formula for determining availability should be the same as the kernel supported
capabilities.
>CAP_SETFCAP (ability to set a capability set on a file)
>
>Mac related:
>CAP_MAC_DOWNGRADE (possibly 1 for int
>CAP_MAC_READ
>CAP_MAC_RELABEL_SUBJ
>CAP_MAC_UPGRADE
>CAP_MAC_WRITE
>
>Audit related:
>CAP_AUDIT_CONTROL
>CAP_AUDIT_WRITE (CAP_AUDIT_READ is also defined, but I'm not sure normal DAC
> won't do)
>
> In the 2.3.99 source, 28 out of 32 caps are used. In IRIX, we
>got by with 47 caps. So I'm just guestimating that 64 should be enough
>for Linux for sometime to come.
>
> (I know...I just think too much).
>
> Second question would be how much of this (saved caps), extra
>caps do we want in the kernel mainstream -- or should those treated
>as 'configurable'? Maybe CAPS should be configurable as well -- considering
>the complaints I've heard over adding security features -- maybe CAPS
>should be taken to a CONFIG-OPTION, if "off", capable(x) becomes a
>#define capable(x) ((int)(current->euid==0)). (Just taking the
>security configurables to some logical point).
>
> Things like accounting are configurables, should caps be? That
>way those who only want to use Linux in an isolated environment where
>they need only speed can not be troubled by those pesky bit-mask ops,
>or the extra memory needed to store the cap words (considering they aren't
>being used by most people, I'm surprised they got in as anything other
>than a configurable)... ???
I think a configuration item would be a very good thing. In fact, a whole
new section ... "Extended Security Options" should be created to hold
capabilities. It could be the place to put MAC capability, perhaps even
IPSec options when these become available. It might even be reasonable
to put the firewall option here (or at least a referece to it).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:15 EST