[ I've directed follow ups to the linux-privs mailing list, to try to
avoid the load on the linux-kernel mailing list. Please respect the
reply-to header. Also, please note that I'm about to move the
linux-privs mailing list to linux-privs-discuss@lists.sourceforge.net
over the next day or so. Linux-privs subscribers will be
automatically subscribed to the new list, and linux-privs@mit.edu will
change to a forwarding pointer pointing at the sourceforge.net list.
Since I'm no longer at MIT, and lists.sourceforge.net allows automatic
list management and archival, this seems to make a lot of sense. ]
Date: Wed, 31 May 2000 17:38:59 -0700
From: Casey Schaufler <casey@sgi.com>
"Theodore Y. Ts'o" wrote:
> On of the problems is that the draft doesn't state how the bits
> would typically get used. For example, what would the PIE permissions
> be on a typical system after login is run?
For your normal user (let's call him Albert) the capset would be
empty, in Irix terms "all=".
Oh, good! That's what I thought; we're not that far apart after all.
It's however not what Linda was stating in her e-mail messages, where
she seems to assert that untrusted users get an I capset of ~0, and that
some uid's might have additional bits set in the P and I capsets:
>law@sgi.com's said on Mon, 29 May 2000 12:47:40 -0700
>
> login, running with PIE=(all,all,all) now wants to "log in"
>user 'backup'. It forks and sets PIE=(01,all,01) (using 01 for
>DAC_READ_SEARCH). This works. So pPIE=(01,all,01)
Does Trusted Irix really work this way?!?
If we want Albert to perform some particular function we might give
him access to some capabilities, which he could get as needed with
"su -C", based on his entry in /etc/capability. It is important to
understand that a capability set doth not a role define, and trying
to make it so is a road to madness.
I certainly agree with your last statement. But you should check and
see what Linda's claims for how capabilities should work. Her claim is
that the backup uid get DAC_READ_SEARCH if you login with that uid,
which certainly sounds like using a capability set as a role-based
mechanism. When this didn't work correctly based the way Linux
implemented things, she claimed this proved that our current mechanism
was broken. I tend to agree with you that it leads to madness.
This confusion about exactly how things are supposed to work really
leads me to believe a face-to-face meeting would be helpful. I've
gotten authorization to host a quick (informal and on short-notice)
meeting at VA while I'm in town in Sunnyvale. Given that some of the
interested parties (SGI folks, Andrew Morgan, myself) will be in the Bay
Area then, it might make sense to try to hash out these issues
in-person and on a white-board. I was thinking perhaps a Friday
afternoon on the June 16th, perhaps? That would be most convenient for
me, but perhaps not for others. Comments?
- Ted
-
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 Jun 07 2000 - 21:00:12 EST