[apparmor] apparmor.vim - profile format changes since 2.3?

[John Johansen]

On 01/11/2011 08:10 AM, Christian Boltz wrote:
> Hello,
> 
> Am Dienstag, 11. Januar 2011 schrieb John Johansen:
>> On 01/10/2011 05:02 PM, Christian Boltz wrote:
> 
>>> Which of the audit, deny, owner keywords are allowed for the
>>> non-file rules?
> 
>>> - set capability
>>
>> dead, and gone.  There where serious security issue with this that
>> were to easy to expose and would have needed fixing.  The
>> recommended replacement solution is using pam_capable in conjunction
>> with pam_apparmor
> 
> Hmm, apparmor_parser doesn't complain about "set capability" - in which 
> version did you remove it?
> Nevertheless: removed / commented out in apparmor.vim.
> 
2.5

> OTOH apparmor_parser complained about some things that I would consider 
> valid:
> 
>    network inet raw tcp,
> 
the current networking implementation can't do this.
you can get
  network inet raw,
  network inet tcp,

but not
  inet raw tcp,

this is the correct syntax though, and this ability is coming

rlimit rules require the set keyword on them, this is mostly done as a hint
that they behave differently that regular rules

>    rlimit data <= 100M,
good with leading set

>    rlimit data <= 10,
good with leading set

>    rlimit locks 20,
set rlimit locks <= 20,

>    rlimit sigpending 12332341234123, # enough ;-)
set rlimit sigpending <= 12332341234123,

>    rlimit nice 10,
set rlimit nice <= 10,

>    rlimit nice -20,
set rlimit nice <= -20,

>    rlimit nice 5,
set rlimit nice <= 5,

> 
>    ^foobar,  # external hat
> 
> Is there something wrong in my (hand-written) example profile or is this 
> a parser bug?
> 
hrmmm I am wondering if your examples came from the early prototype for
rlimit.  That version was slightly different, in it allowed specifying
the soft limit and the hard limit.

And I don't think it required the <=

Basically the current syntax isn't the best but it emphasizes the current
limitations.  AppArmor isn't actually controlling the rlimits, it just
setting values in the rlimit table, and ensuring that a task can not
raise the limit past what is specified in the profile.

Tasks are free to raise or lower soft and hard limits as long as they
don't go past what is specified by the profile.

Also rlimits not specified in the profile are not restricted by apparmor.

There are a couple things I would like to fix with the rlimits implementation.
I would like to make it possible to specify that an rlimit can't be changed,
and in those cases a value should be optional.



>>> - network
>>
>> owner isn't currently supported but will be
> 
> I'm slightly surprised - how can a network connection have an owner?
> 
Its may seem a little odd but it can make sense when sockets get passed.
Generally the "owner" of the socket is determined by who created the
socket.

I don't see this being all that useful but it seems like more work to
disable this ability than allow access to it (sockets inherit it from
the common mediation code with files).

> Besides that, I had to learn that vim has a restriction on the number of 
> (...) I may use in a RegEx (up to 9 are allowed), and therefore had to 
> change the RegEx that matches tcp/udp/icmp from "(\s+(tcp|udp|icmp))?" 
> to "(\s+tcp|\s+udp|\s+icmp)?". *argh*   [1]
> 
> The latest apparmor.vim is attached.
> 
> 
thanks

> Regards,
> 
> Christian Boltz
> 
> [1] one more reason to auto-generate apparmor.vim with a script:
>         join ('|\s+', $array)
>     (doing this manually is errpr-prone and painful ;-)
>     Or, worst case, I could generate several similar lines (so that I 
>     don't need "(...)" for audit, deny and owner) without causing a 
>     maintenance hell.
>