- suid code: I notice that the daemon drops perms before loading the TLS private key file. It would be better to load the file first, so that only root needs read access to the private key - does the current TLS module architecture support that?
- comments on 1024 bit RSA: the docs recommend not to use key sizes > 1024. http://kamailio.org/docs/modules/devel/modules/tls.html#certificate However, this seems to be the opposite of what virtually all security experts are now saying: most people believe 2048 is bare minimum and 4096 is the better choice for new deployments where no legacy clients might exist
- also related the above issue, the doc says `bytes', I think it means to say 1024 bits
- is there a compelling reason to use hard-coded IP addresses for SIP config files? For all my apps that have special IP requirements, I always create dedicated DNS names for each of my virtual/interface IPs. Then I like to put that dedicated DNS name (rather than just the hostname) in the config file. The listen= directive in kamailio.cfg doesn't appear to support this though.
- DB setup - I notice that the kamdbctl script expects to make databases and make tables in one step. It is not unusual for a security-conscious admin to deny DBA access from app servers (e.g. the server where kamailio is installed). Maybe kamdbctl needs an option to skip DB creation, and just do table creation? I found I could achieve this just by editing:
/usr/lib/kamailio/kamctl/kamdbctl.mysql
and commenting the `exit 1' line in this code: if [ $? -ne 0 ] ; then merr "Creating core database and grant privileges failed!" #exit 1 fi
- an alternative solution might be to modify kamdbctl so that it just connects in read-only mode to make any checks, writes all the DDL statements to a file that the SIP admin can give to their DBA (or even if it is the same person, they may have a standalone MySQL box, and they don't want to install all of kamdbctl on that box)
29 jan 2012 kl. 11:34 skrev Daniel Pocock:
- suid code: I notice that the daemon drops perms before loading the TLS
private key file. It would be better to load the file first, so that only root needs read access to the private key - does the current TLS module architecture support that?
Seems to be a good fix.
- comments on 1024 bit RSA: the docs recommend not to use key sizes > 1024.
http://kamailio.org/docs/modules/devel/modules/tls.html#certificate However, this seems to be the opposite of what virtually all security experts are now saying: most people believe 2048 is bare minimum and 4096 is the better choice for new deployments where no legacy clients might exist
Agree.
- also related the above issue, the doc says `bytes', I think it means
to say 1024 bits
Agree.
- is there a compelling reason to use hard-coded IP addresses for SIP
config files? For all my apps that have special IP requirements, I always create dedicated DNS names for each of my virtual/interface IPs. Then I like to put that dedicated DNS name (rather than just the hostname) in the config file. The listen= directive in kamailio.cfg doesn't appear to support this though.
Listen indicates exactly interfaces and IPs to listen to. Alias adds the list of DNS names the server is authoritative for. I think the current setup is fine.
- DB setup - I notice that the kamdbctl script expects to make databases
and make tables in one step. It is not unusual for a security-conscious admin to deny DBA access from app servers (e.g. the server where kamailio is installed). Maybe kamdbctl needs an option to skip DB creation, and just do table creation? I found I could achieve this just by editing:
/usr/lib/kamailio/kamctl/kamdbctl.mysql
and commenting the `exit 1' line in this code: if [ $? -ne 0 ] ; then merr "Creating core database and grant privileges failed!" #exit 1 fi
Agree with this change.
- an alternative solution might be to modify kamdbctl so that it just
connects in read-only mode to make any checks, writes all the DDL statements to a file that the SIP admin can give to their DBA (or even if it is the same person, they may have a standalone MySQL box, and they don't want to install all of kamdbctl on that box)
I would suggest you open a few bug reports on these issues so the developers can look at it. If you already have code, you can submit it there as well.
Thanks! /O
I would suggest you open a few bug reports on these issues so the developers can look at it. If you already have code, you can submit it there as well.
I regularly tweak things and share the fixes - but usually I find it helpful to get other people's perspectives (and in some cases, uncommitted changes) before I put time into something
The first thing I was going to fix was intermediate CA support, but then I found it is just not documented, so I've tested it and shared my findings about that on the users list.
-
Daniel Pocock -
Olle E. Johansson