On 05/21/2015 10:04 AM, Paul Moore wrote:
On Thu, May 21, 2015 at 9:54 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 05/21/2015 09:50 AM, Stephen Smalley wrote:
On 05/21/2015 09:43 AM, James Carter wrote:
Do you have something else in mind that might use the operation structures?
In CIL we will probably make the syntax something like this:
((allowop <source> <target> <class> <ioctl expression>)
So the above rule might look like:
(allowop <source> <target> <class> ((range 0x8910 0x8926) 0x892A))
Paul asked to generalize it so it can be reused for other purposes. One
example would be netlink message types. Today, there is a hardcoded
table in SELinux (security/selinux/nlmsgtab.c) that maps specific
netlink message type values to nlmsg_read (i.e. reads public kernel
state), nlmsg_readpriv (i.e. reads potentially sensitive kernel state),
nlmsg_write (i.e. modifies kernel state), and a few other audit-specific
values so we can distinguish e.g. who can read vs write routing table
entries or audit configuration, as the normal socket read/write checks
merely control the ability to send/recv on the socket, which is always
required for any user of it. That has limited flexibility and isn't
generally well maintained for newer netlink protocols.
So the proposal would be to just add an additional field specifying how
to interpret/apply the operation list, e.g.
(allowop <source> <target> <class> <ioctl|netlink|...> ((range 0x8910
0x8926) 0x892A))
Looks to me like a good solution for CIL.
I agree.
So why not have a syntax like the following for checkpolicy?
allowop <source> <target> <class> <ioctl|netlink|...> { 0x8910-0x8926 0x892A };
Woudln't that be clearer?
--
James Carter <jwcart2@xxxxxxxxxxxxx>
National Security Agency
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
